Skip to content
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

Add javax.annotation.processing.Generated for Java 9 #835

Closed
ben-manes opened this issue Feb 25, 2018 · 12 comments
Closed

Add javax.annotation.processing.Generated for Java 9 #835

ben-manes opened this issue Feb 25, 2018 · 12 comments
Milestone

Comments

@ben-manes
Copy link
Collaborator

Java 9 replaces javax.annotation.Generated with javax.annotation.processing.Generated, with the former removed for compatibility. The former is not compatible with JDK9 due to split packages (Jigsaw modules).

Unlike other static analyzers, Google's ErrorProne does not support excluding directories from analysis. Instead it uses the above annotations as an ignore rule. Since neither are generated any longer, the rules are enforced. Other analyzers are likely to follow this idiom as they become Java 9 compatible.

It would be nice to have an option to enable this annotation, with the correct one chosen based on the Java version.

@joelittlejohn
Copy link
Owner

Do you think it is acceptable to check the current runtime when generating classes, or should it be possible to e.g. target Java 8 even though your build is running with Java 9?

@ben-manes
Copy link
Collaborator Author

In this case the runtime is fine, since it is a backwards compatibility issue with the jdk, but I don’t have a strong preference.

@ben-manes
Copy link
Collaborator Author

Closing because I got this to work in ErrorProne. I must have missed the configuration option to exclude a director.

tasks.withType(JavaCompile) {
  options.errorprone {
    disableWarningsInGeneratedCode = true
    excludedPaths = "${buildDir}/generated-sources/.*"
  }

@Art-B
Copy link

Art-B commented Aug 21, 2018

Why was this closed? It seems like a valid feature even if there is a work around for a particular scenario? It seems like having the Java version being target passed in seems reasonable. It would allow for the generation of more idiomatic or faster code etc in the future.

I am currently just researching for an option to enable the annotation even if only for the IDE warning.

@ben-manes
Copy link
Collaborator Author

Sorry, I closed it since the use-case was no longer pressing and, since I wasn't going to do the work, it seemed impolite to throw on @joelittlejohn's plate unnecessarily. You are welcome to reopen / refile.

@joelittlejohn
Copy link
Owner

Happy to reopen this.

@sergeykad
Copy link

There is an existing Google utility that returns a correct annotation. It can be used to add a correct one depending if it is Java 8, Java 9+ or Android.

https://github.com/google/auto/blob/master/common/src/main/java/com/google/auto/common/GeneratedAnnotations.java

@cyclotomic18
Copy link

How come this issue was never addressed with enough importance? Imho this feature is a required one for a (Java) code-generation tool.
In fact, at the moment this tool is not good enough to be used in environments where error checkers/code coverage/quality gates etc. (SonarQube, ErrorProne...) are managed by some client's organization and not by developers themselves. How do you exclude generated code from quality gate checks on a CI/CD where you can only control source code?

Most of the most-used code-generation tools (openapi/swagger, jaxb, lombok etc) do have this feature, feature that can be enabled/disabled by some sort of switch, like "markGenerated" or equivalent.

So why was this removed just because "Android users had issues"? Isn't it possible to restore the feature and conditionally drive the annotation addition based on a switch (and then eventually by the java runtime version, if needed)?

@joelittlejohn
Copy link
Owner

@cyclotomic18 the annotation was removed because Android users are a significant minority of users and it was a source of many support issues and confusion.

I do agree though, we should add the annotation back in.

@cyclotomic18
Copy link

@joelittlejohn Thank you very much for your reply.
How and when is this going to happen? Does it require much effort to restore and eventually tweak the required code?

I am planning to use (in fact, actually using as a first option in early development stages) json-schema in combination with this tool in a project for my company; but there's no point in even attempting a poc if that feature's absent, so it would be appreciated to have an estimate for that.

@joelittlejohn
Copy link
Owner

@cyclotomic18 If you require it, please just fork and add this feature (this is why the code is open and licensed such that you are free to make any modifications you like with minimal obligation). We can look to add this in the next version, but I'm afraid I can't commit to anything.

@cyclotomic18
Copy link

I opened pull request #1202

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants