-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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.
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
compiler: add option @generated=jakarta #11215
Conversation
As mentioned in #9179, we don't want a dependency on jakarta. The dependency was originally part of the JDK itself. Disable the annotation or take a look at #9179 (comment) to see about creating a new annotation in gRPC itself. |
@ejona86 this is an opt-in feature that would be at the discretion of users / consumers of the tool, right? The default behaviour ( We're using JDK 22, and the framework we use only supports |
In what way does
That's literally what everyone else had to do since Java 9. |
@ejona86 In what way does
Great. Now why don't we modernise (as other frameworks and tooling have done) rather than perpetuating this indefinitely? |
We were never trying to depend on J2EE. We were depending on the JRE. But then the JRE moved stuff into J2EE. And then J2EE was replaced with a new J2EE. We want to solve this by stopping depending on J2EE, not replace it with the new J2EE. |
The reality of the situation is that J2EE has been adopted as the defacto standard and is supported by major frameworks (Micronaut, Spring, Quarkus, etc). This pull request doesn't add a direct dependency on J2EE to https://www.eclipse.org/community/eclipse_newsletter/2019/may/javax.php |
Is there a reason for keeping the |
"supports it"? How does this benefit J2EE users?
To my knowledge nothing is marked |
@ejona86 Because it makes use of a framework that has long been considered the defacto standard (and is used as such). I don't understand the opposition to this pragmatic change - it adds no maintenance or support overhead and is beneficial to real-world use-cases and users. The funny/sad thing is that this has been an open issue since 2017/2022 and nothing has been done to remedy it. I don't understand why something so simple has been neglected for such a long time, as there doesn't seem to be a compelling reason for doing so. This feels like a scenario in which the pursuit of perfection is being used as the enemy of good enough. |
In what way does this do that?
I still don't understand why omitting the annotation is not "good enough" for you. |
Because we want an annotation to be emitted. |
That is circular. What behavior are you wanting from the annotation? |
To denote that code was automatically generated and to be treated as such. |
But why this specific annotation? You can communicate it was generated with a comment. That sounds fine. And #9179 is to create a grpc-specific annotation. What's wrong with that? |
Because |
We have no desire to depend on jakarta. |
You realise this adds no dependency on Jakarta right? It just adds optional support for users who wish to use it. |
An optional dependency is a dependency. And the need here is zero. |
Add (optional) support for
@jakarta.annotation.Generated
while retaining existing functionality.An extension of #11086