JDK13 annotation processors not run when a supported annotation type specifies a module

Jeremy Kuhn jeremy.kuhn.java at gmail.com
Thu Jan 16 23:48:05 UTC 2020


I've just ran into this issue while testing annotation processors with
JDK13. It happens when you specify a @SupportedAnnotationTypes annotation
with annotation names prefixed with composite module names like the

public class ModuleAnnotationProcessor extends AbstractProcessor {

This is perfectly valid according to the documentation and was working just
fine until JDK13

"the name of the annotation type can be optionally preceded by a module
name followed by a "/" character. For example, if a processor supports "a.B",
this can include multiple annotation types named a.B which reside in
different modules. To only support a.B in the Foo module, instead use
"Foo/a.B". If a module name is included, only an annotation in that module
is matched. In particular, if a module name is given in an environment
where modules are not supported, such as an annotation processing
environment configured for a source version
without modules, then the annotation types with a module name do *not*
match." --

I've track down the issue in JavacProcessingEnvironment.java to the
following commit:

Some checks have been added to make sure supported annotation strings are
valid and proper warning reported, unfortunately there's an error in the
module's name check:

private static Pattern importStringToPattern(boolean allowModules, String
s, Processor p, Log log, boolean lint) {
    else {
            String moduleName = s.substring(0, slash);
            if (!SourceVersion.isIdentifier(moduleName)) {
                return warnAndNoMatches(s, p, log, lint);

A module name is not a simple identifier like "moda", "com.example.moda" is
also a valid module name as stated in the Java Language Specification
(7.7). This results in always returning a no match pattern when such module
name is used and the processor basically ignored.

If we do not prefix the annotation with a module name, so there is a
workaround but that doesn't match the API doc.

Please let me know if I can help!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200117/57efd678/attachment.htm>

More information about the compiler-dev mailing list