[Jigsaw] Getting "Bad service configuration file" error with annotation processor

Alan Bateman Alan.Bateman at oracle.com
Tue Feb 9 20:33:33 UTC 2016

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 


More information about the compiler-dev mailing list