-
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
Remove dependency on javax.annotation.Generated #6833
Comments
/cc @srini100 |
A quick note that The biggest problem with the annotation is there are so many different artifacts containing it, which causes classpath collisions. (I'll also note that the dependency is |
Java 9 has javax.annotation.processing.Generated, which seems to be the proper replacement? You're right that the Generated annotation is not necessary at runtime, but the "default" (?) maven artifact also contains other annotations that are not compile-only, so you'd have to be very careful not to accidentally use one of them elsewhere. |
See #3633 concerning |
Ok, I'll try hard not to reopen that discussion. Would it be a hardship for you to add a flag that allows the user to select the annotation (or disable it)? The mentioned I've worked around the issue for us, but it seems risky to recommend using CDDL-licensed code. |
There is Normally we can't have options for the generated code because we need there to be a canonical version used by everyone (otherwise we start seeing diamond dependency issues). Since this annotation is source-level only, it would be possible to have an option for it. But in general it would be best for everyone to resist options. For example, in this case we may change our recommendation to use |
closing it due to inactivity, please feel free to reopen. |
I can't reopen bugs in this project, so that statement feels a bit passive-aggressive. I think having a dependency on CDDL-licensed code is a problem - even if only a burden on your users to make sure that they don't accidentally include it in whatever they're distributing -, and I'm happy to send a patch if there's agreement on what to do. Personally I would use the javax.annotation.processing.Generated annotation in the JDK; I understand the concern that it's intended for annotation processing, but I personally think that concern is academic. I'd also be happy with removing the annotation, but I don't know if anyone's relying on it. |
(@ulfjack, @creamsoup was not aware you couldn't reopen issues. All the same, we normally would say "comment with more information and we can reopen") I saw this had been closed, but I didn't realize it was this. Yeah, this should remain open. The inactivity is on our side (i.e., me). |
javax.annotation-api is licensed CDDL, which was not noticed when it was introduced. Tomcat provides an Apache 2 version of the same annotation. Note that this annotation is only used when compiling with Java 9+. Unfortunately this may cause classpath collisions since there are _many_ copies of this annotation on Maven Central; we wanted one canonical source and javax.annotation-api seemed like that source. We hope this won't impact many users since we have always suggested using it only for compilation. But it will probably impact some users. However, we didn't create this mess, this seems to be "standard practice" for J2EE, which this annotation is now part of, so we're just impacted by it. Fixes grpc#6833
javax.annotation-api is licensed CDDL, which was not noticed when it was introduced. Tomcat provides an Apache 2 version of the same annotation. Note that this annotation is only used when compiling with Java 9+. Unfortunately this may cause classpath collisions since there are _many_ copies of this annotation on Maven Central; we wanted one canonical source and javax.annotation-api seemed like that source. We hope this won't impact many users since we have always suggested using it only for compilation. But it will probably impact some users. However, we didn't create this mess, this seems to be "standard practice" for J2EE, which this annotation is now part of, so we're just impacted by it. Fixes grpc#6833
javax.annotation-api is licensed CDDL, which was not noticed when it was introduced. Tomcat provides an Apache 2 version of the same annotation. Note that this annotation is only used when compiling with Java 9+. Unfortunately this may cause classpath collisions since there are _many_ copies of this annotation on Maven Central; we wanted one canonical source and javax.annotation-api seemed like that source. We hope this won't impact many users since we have always suggested using it only for compilation. But it will probably impact some users. However, we didn't create this mess, this seems to be "standard practice" for J2EE, which this annotation is now part of, so we're just impacted by it. Fixes #6833
that's a known issue fix grpc grpc/grpc-java#3633 why is not javax.annotation-api see here grpc/grpc-java#6833
that's a known issue with grpc grpc/grpc-java#3633 why is not javax.annotation-api see here grpc/grpc-java#6833
that's a known issue with grpc grpc/grpc-java#3633 why is not javax.annotation-api see here grpc/grpc-java#6833
javax.annotation-api is licensed CDDL, which was not noticed when it was introduced. Tomcat provides an Apache 2 version of the same annotation. Note that this annotation is only used when compiling with Java 9+. Unfortunately this may cause classpath collisions since there are _many_ copies of this annotation on Maven Central; we wanted one canonical source and javax.annotation-api seemed like that source. We hope this won't impact many users since we have always suggested using it only for compilation. But it will probably impact some users. However, we didn't create this mess, this seems to be "standard practice" for J2EE, which this annotation is now part of, so we're just impacted by it. Fixes grpc#6833
A similar issue was previously reported in #5343, which I cannot reopen. The problem with the solution proposed there is that the upstream library that is pulled this way is licensed under the CDDL. You should probably talk to a lawyer about the implications of that, and whether they apply here.
In any case, given that gRPC seems to be intended to be licensed as Apache 2, it seems wiser to remove the dependency entirely or at least provide an option to avoid it.
The text was updated successfully, but these errors were encountered: