Why defer all the elements of the problematic element's enclosing TypeElement?

[AriaAdibi]

As I understood, when an element E is deferred in a step the way basicAnnotationProcessor behaves is that it will defer all elements of the enclosing TypeElement of E, regardless of whether or not they have already been properly processed. My question is what is the benefit of this behavior? Why not just defer the problematic element?

One negative aspect is that when the annotation to be processed targets methods only for example, and for each annotated method it acts independently, then this behavior is undesirable and some hacks are needed if we want to successfully process each annotated method only once (this is needed for example, if after successful completion Filer is used to create a source code). Is this annotation design bad in your opinion? Why? If not, what would you suggest as a remedy?

Thank you.

[eamonnmcmanus]

It's an interesting question. The JDK documentation for annotation processors isn't all that clear, but it does say this about the method Processor.process:

Processes a set of annotation interfaces on type elements originating from the prior round and returns whether or not these annotation interfaces are claimed by this processor.

[emphasis added]

So following this documentation, if you have an annotation on a method then that in itself should not be enough to trigger a processor for that annotation. Only annotations on type elements should trigger it. (The weird thing is that, as far as I can see, there is no method to return just the set of TypeElements with the annotation, perhaps because that wouldn't make sense for wildcard (*) processors. You can of course get that set by calling RoundEnvironment.getElementsAnnotationWith and filtering with ElementFilter.typesIn.)

Following that, then, the BasicAnnotationProcessor model is essentially the same except that at each round you have both "type elements originating from the prior round" and "type elements deferred from the prior round".

[AriaAdibi]

Thank you for the prompt answer!

As you mentioned, I have used regular Sun's Javac for windows and was able to catch the aforementioned method-specific annotations with no problem.
It is interesting that only Processor.process mentions this. In other places in the document, there is no limitation on the type of the element. For example, it says

For a given round, the tool computes the set of annotation types that are present on the elements enclosed within the root elements.

Just one last question. I did not understand why limiting the elements to TypeElement would not make sense for the wildcard processors; would you mind explaining that, please?

[eamonnmcmanus]

I confirm that an annotation on a method is in fact enough to trigger a processor for that annotation. That suggests that BasicAnnotationProcessor could indeed be refined so that it defers just the annotated element. I think that might be a little tricky in practice because if a method references an as-yet-undefined type then its enclosing class is considered also to reference that type, transitively. The current model is that only types are deferred, and this happens when they or any of their members reference undefined types. We could imagine refining the model so that if an annotated element (say a method) references undefined types, and no other member of the containing class does, then we defer just that method. I think that could be fairly complicated to get right, though.

My comment about wildcard processors would only make sense if processors were only triggered for TypeElements, which as we've established isn't the case.

[eamonnmcmanus]

Incidentally it isn't guaranteed that elements are represented by the same object in each round. They are with javac but, last I looked, they weren't with ecj (the Eclipse compiler). That's not much of a problem with TypeElement, because it's easy to defer the name of the TypeElement and recover it in the next round. That would be trickier for methods, at least if you allow overloads.