The javax.annotation.Generated and annotation processors

[Sanne Grinovero]

On Fri, Apr 22, 2016 at 8:47 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 22/04/2016 19:55, Sanne Grinovero wrote:
>>
>> Hello all,
>>
>> related to https://bugs.openjdk.java.net/browse/JDK-8152842
>>
>> I'm having to patch our annotation processors to avoid the @Generated
>> annotation, as I can't use the proposed workaround to use `-addmods
>> java.annotations.common`: our build also requires `-target 1.7` and
>> the two options are not compatible.
>>
>> But I hope this will be only very short term? I'm only working this
>> around temporarily so that I can keep testing other more interesting
>> aspects of Jigsaw, but ultimately we'll need that annotation back.
>>
>> Thanks,
>> Sanne
>
> There's two issues here.
>
> One is that when you run `javac` then the you are essentially executing the
> jdk.compiler module. This module is resolved at startup and the transitively
> closure (+ services) is restricting the set of modules that can be read by
> your annotation processor (that is in its own unnamed module). We had a
> small update that we need to do in JEP 261 to support this and at the same
> time align with the updated policy on root modules when executing code in
> the unnamed module. So assume that `javac`, `javadoc` and several other
> tools will be updated with this soon.
>
> The other issue is specific to the java.corba module and the 5 modules that
> are shared with Java EE. These are not resolved by default so this is why
> `-addmods` (or `-J-addmods` if javac -processor and the annotation processor
> needs the module to be resolved) is needed. In the other thread then you are
> happy that the EE version of Java Transaction API is located in preference
> to the subset in the JDK, in this case you want the Java SE subset of the
> Common Annotations. It's impossible to fix all cases without going back to
> split packages again.
>
> On combing options then if you are compiling with `-target 1.7` then I
> assume you must be also specifying `-source 1.7` and `-bootclasspath ...`
> and so `-addmods` isn't in the picture. Better still then `javac -release 7`
> should do it.
>
> On the other hand, if this its the annotation processor using @Generated
> then I would expect this should work:
>     -J-addmods -Jjava.annotations.common -processor ... -release 7
>
> The -J is the way to pass options through to the underlying runtime (or
> execution environment in javac speak).

Thanks Alan for these explanations, your guidance is proving essential
while I'm falling deeper in this wonderland.

I can't use "-release 7" as our code needs to be built with JDK8 (at
least): it has support for dealing with the new Date/Time APIs from
Java8, yet it falls back gracefully to disable such functionality when
run on Java 7.
I realize that I have plenty of alternatives to break that in separate
units - but I'll spare you such off topic details.

It's good to know that other simpler projects should be able to
benefit from your above suggestions.

I couldn't try the "-J-addmods -Jjava.annotations.common" solution
either, I suspect because Maven is getting in the way and possibly
passing these parameters in the wrong order; for the record this is
the stack:

Caused by: java.lang.IllegalArgumentException: invalid flag: -J-addmods
    at com.sun.tools.javac.main.Arguments.error(jdk.compiler at 9-ea/Arguments.java:779)
    at com.sun.tools.javac.main.Arguments.doProcessArgs(jdk.compiler at 9-ea/Arguments.java:378)
    at com.sun.tools.javac.main.Arguments.processArgs(jdk.compiler at 9-ea/Arguments.java:294)
    at com.sun.tools.javac.main.Arguments.init(jdk.compiler at 9-ea/Arguments.java:250)
    at com.sun.tools.javac.api.JavacTool.getTask(jdk.compiler at 9-ea/JavacTool.java:175)
    at com.sun.tools.javac.api.JavacTool.getTask(jdk.compiler at 9-ea/JavacTool.java:109)
    at com.sun.tools.javac.api.JavacTool.getTask(jdk.compiler at 9-ea/JavacTool.java:65)
    at org.bsc.maven.plugin.processor.AbstractAnnotationProcessorMojo.executeWithExceptionsHandled(AbstractAnnotationProcessorMojo.java:527)

But found a solution: your suggestion that this is a similar problem -
but opposite - then what I had with the Java EE APIs was spot on:
I simply added the API jar from jsr250 "javax.annotation" on the
classpath of the annotation processor and it's all working nicely.

I noticed something else which might be of interest. We build the
project in two distinct phases: annotation processor(s) first,
compilation second.
I'm surprised to see that the second phase is working fine even though
I did not add the jsr250 dependency; I didn't investigate further but
it seems like the compiler knows that this annotation is annotated
with "@Retention(SOURCE)" ?!

For those using Maven, I pasted an example of this solution here:
 - https://issues.jboss.org/browse/LOGTOOL-105?focusedCommentId=13196069

BTW all these questions I've been sending recently relate to a popular
open source project. If anyone would like to experiment with the same
projects it's available at
https://github.com/hibernate/hibernate-search .
It might be of interest as it runs all of: Hibernate ORM, Apache
Lucene, Elasticsearch, WildFly, JGroups, ApacheMQ which are all very
popular in the Java community, and runs integration tests within
Spring/JavaSE, within WildFly (JavaEE), with modules systems: both
OSGi & JBoss Modules, uses bytecode manipulation including Javassist
proxies, tests driven by Byteman, and finally building the
documentation requires JRuby.

Thanks,
Sanne


>
> -Alan