8000 Introduction of @Mixin annotation to generate code by verhasi · Pull Request #34977 · spring-projects/spring-framework · GitHub
[go: up one dir, main page]
Skip to content

Introduction of @Mixin annotation to generate code #34977

8000
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 2 commits into from
Closed

Introduction of @Mixin annotation to generate code #34977

wants to merge 2 commits into from
+69 −95

Conversation

verhasi
Copy link
@verhasi verhasi commented May 31, 2025

In the MultiValueMapAdapter there are a lot of boilerplate codes to implement the Map interface that has a maintaining cost. Mocker Guru's Mixin annotation and annotation process is capable to generate these codes at compile time without any runtime dependency.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label May 31, 2025
@bclozel
Copy link
Member
bclozel commented May 31, 2025

Thanks for the proposal but we don't think that adding a new module and depending on a new dependency strikes the right balance here. That class does not cause a lot of maintenance burden so we would rather keep things as they are for now.
Thanks!

@bclozel bclozel closed this May 31, 2025
@bclozel bclozel added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels May 31, 2025
@verhasi
Copy link
Author
verhasi commented Jun 2, 2025

Hi @bclozel,

Thank you for your quick response. Lets look at closer one by one.
The Mixin itself is not requiring the introduction of a new module. It is a consequence of Spring Framework (SF) specific chain of requirements and context. The build of SF requires that all the warnings are error (-Werror compiler option) and fail the build. Until now there is no annotation processing in the SF build. The Java compiler has an interesting "feature" to warn about annotations that were not claimed by any annotation processor but only in case if at least one annotation processor is activated. As in the SF there are annotations for only runtime they are not processed at compile time. The new module introduction targets to imitate the processing of these annotations. So it is not Mixin specific, introduction of any kind of annotation processor would require to handle this warning/error. Another option could be to switch off all the warning of annotation processing but I thought this one would be the preferred.
Regarding the new dependency is two folded. The annotation itself is a compile time only dependency and contains only the annotation and no code at all. The annotation processor is also a compile time only dependency and has no runtime dependency. The generated source code is fully transparent.
I see that for only one class it would be unbalanced but I have already identified other classes for delegation. Further analysis of the big code base could emerge other potential classes to apply the Mixin pattern. I believe the final balance will be positive.
Thank you for reconsidering these points of view.

Best regards,
István

@bclozel
Copy link
Member
bclozel commented Jun 2, 2025

Thanks for the additional information. For now, we have not identified this as a particular maintenance problem and we consider that making our build more complex would be a downside. So we'd rather stick to what we have right now 76F6 and reconsider later if we think that we would like to tackle such problems in our codebase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@verhasi @bclozel @spring-projects-issues
0