Add javax.annotation.processing.Generated for Java 9

[ben-manes]

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]

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]

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]

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]

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]

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]

Happy to reopen this.

[sergeykad]

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]

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]

@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]

@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]

@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]

I opened pull request #1202