-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
17
-
generic
-
generic
A DESCRIPTION OF THE PROBLEM :
When multiple annotation processors are given (using the -processor argument), a processor with @SupportedAnnotationTypes("*") can be prevented from running by any other annotation processor that claims any annotations on a class. This is extremely confusing; it seems that an annotation processor with @SupportedAnnotationTypes("*") should be invoked on every class, regardless of what other annotation processors ran.
For example, this problem arises in practice when trying to use Lombok and the Checker Framework together (two extraordinarily popular annotation-processor-based tools). However, the problem is not specific to those tools.
The problem appears to be that after an annotation processor "claims" all of the annotations on a class---even if it is only trying to claim specific annotations---then processing stops immediately.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
javac demo/AP1.java demo/AP2.java demo/Annotation.java
javac -processor demo.AP1,demo.AP2 demo/Main.java
Where:
- demo.Annotation is an @interface
- demo.AP1 is an annotation processor that claims "demo.*" annotations (i.e. it has @SupportedAnnotationTypes("demo.*") and its process method returns true)
- demo.AP2 is an annotation processor has @SupportedAnnotationTypes("*") and its process method returns false
- demo.Main is a class annotated with @demo.Annotation
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Both annotation processors (demo.AP1 and demo.AP2) should get a chance to run.
ACTUAL -
Only demo.AP1 runs.
CUSTOMER SUBMITTED WORKAROUND :
In this case, since demo.AP2 does not claim any annotations (its process method returns false), reversing the order specified on the command line will work around the problem:
javac -processor demo.AP2,demo.AP1 demo/Main.java
However, this approach is extremely brittle. It relies on implementation details of the individual processors and the order in which javac runs processors.
FREQUENCY : always
When multiple annotation processors are given (using the -processor argument), a processor with @SupportedAnnotationTypes("*") can be prevented from running by any other annotation processor that claims any annotations on a class. This is extremely confusing; it seems that an annotation processor with @SupportedAnnotationTypes("*") should be invoked on every class, regardless of what other annotation processors ran.
For example, this problem arises in practice when trying to use Lombok and the Checker Framework together (two extraordinarily popular annotation-processor-based tools). However, the problem is not specific to those tools.
The problem appears to be that after an annotation processor "claims" all of the annotations on a class---even if it is only trying to claim specific annotations---then processing stops immediately.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
javac demo/AP1.java demo/AP2.java demo/Annotation.java
javac -processor demo.AP1,demo.AP2 demo/Main.java
Where:
- demo.Annotation is an @interface
- demo.AP1 is an annotation processor that claims "demo.*" annotations (i.e. it has @SupportedAnnotationTypes("demo.*") and its process method returns true)
- demo.AP2 is an annotation processor has @SupportedAnnotationTypes("*") and its process method returns false
- demo.Main is a class annotated with @demo.Annotation
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Both annotation processors (demo.AP1 and demo.AP2) should get a chance to run.
ACTUAL -
Only demo.AP1 runs.
CUSTOMER SUBMITTED WORKAROUND :
In this case, since demo.AP2 does not claim any annotations (its process method returns false), reversing the order specified on the command line will work around the problem:
javac -processor demo.AP2,demo.AP1 demo/Main.java
However, this approach is extremely brittle. It relies on implementation details of the individual processors and the order in which javac runs processors.
FREQUENCY : always