-processorpath & META-INF/services/javax.annotation.processing.Processor

[Jesse Glick]

I have not seen any mention of how Jigsaw will load 269-compliant annotation processors.

First of all, if the processor is bundled with the annotation(s) it processes, which is common, and registered in ServiceLoader fashion, then you would expect that just 
requiring that module would suffice to run the processor on your code. This in fact works today in JDK 6 and 7 if you use javac. Frustratingly, the Processor Javadoc is 
evasive on the subject, claiming that it is up to the "tool", and Eclipse's compiler does not honor this convention. [1] It would be nice if 269 + Jigsaw could say 
definitively that if module A provides javax.annotation.processing.Processor with some processor impl, then compilation of a module requiring A will run that processor if 
there are matching annotations (*).

Second, for cases where it is undesirable or impossible to collocate the processor with its supported annotations, there needs to be some way for a module using the 
annotations to explicitly request that this processor be run. -processorpath works in older JDKs, but this is contrary to the style of modulepath. I would expect some 
module-info.java declaration such as

  requires processor proc.module.name @ 1.0;

which would produce no runtime dep compiled into module-info.class, and (like -processorpath) would not expose any public types from proc.module.name, but would check 
proc.module.name for provided Processor's.

Less commonly, you might need a syntax for invoking particular processors by class name and/or passing processor arguments. Of course you can add -processor/-A to the 
javac command line, but this is most suitable when running the processor for some one-off purpose like static analysis. If the processor is needed by the module sources 
(for error checking on annotations, generating resources, and/or generating classes) then it would be more appropriate for this configuration to be permanently declared 
in module-info.java.


(*) Unlike some service locator frameworks, ServiceLoader is incapable of lazily loading services matching some declarative pattern, which can affect client application 
startup time - and in the case of Processor, compilation time. In the NetBeans source base we have around 37 processors registered in SL style, and a single module's 
classpath might well contain a dozen or more. Each of these classes must be loaded (possibly triggering loading of related classes) just to call 
getSupportedAnnotationTypes, even though this metadata is almost always static and most available processors will not be needed.


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=280542