On 09/02/2016 19:08, Gunnar Morling wrote:
:
Note that one stumbling block was a NoClassDefFoundError related to
javax.annotation.Generated raised from within the processor: The
processor adds this annotation to the sources it generates and for
that purpose it accesses Generated.class. I added "requires
java.annotations.common" to the module-info.java of the module under
compilation (i.e. the module to which the processor is applied), but
this didn't help.
Eventually I could make it work by adding a JAR containing the JSR 250
classes to "-processorpath". But I am wondering whether that's the
right approach as these classes are provided by the JDK. Is there a
way to have modules such as "java.annotations.common" exposed to
"pre-Jigsaw" processors?
I assume the issue here is that module java.annotations.common is not in
the boot Layer. That is, when you run javac then the initial module is
jdk.compiler and the only modules in the boot layer will be
jdk.compiler, its transitive dependences, and a few other service
provider modules that get located by means of service binding.
At run-time then it's possible that javac will load and run annotation
processors that have dependences beyond the set of modules that the
container (javac in this case) transitively requires. This will explain
why you get NoClassDefFoundError when you run a legacy processor. On the
other hand, if the processor is a module then I would expect that
resolving its initial module will fail. I'm guessing you must have got a
ResolutionException, I wouldn't expect javac to hide that.
For now then then add -J-addmods -JALL-SYSTEM to the javac command and I
expect this will workaround the hissue. Given that javac is a container
then we may need to have its launcher add these options. This doesn't
help when javac is invoked programmatically of course as whatever is
invoking the javax.tools API may have restricted the modules in the boot
layer.
-Alan.
