Invoking code generated by an annotation processor

[Joseph D. Darcy]

Hello,

On 2/17/2016 11:00 AM, Jonathan Gibbons wrote:
> Stéphane,
>
> Internally, during the period before anno processing, javac 
> categorizes errors as recoverable or not, where "recoverable" means 
> "could this error conceivably be fixed by running annotation 
> processors, which may generate code."
>
> It may be that we have to examine the scenario you describe to decide 
> if the error should be marked as recoverable.
>

To provide some additional historical context here, the first generation 
annotation processing of apt in JDK 5 as well as the standardized 
successor of javax.lang.model and javax.annotation.processing in JDK 6 
and later shared a requirement of having to be able to process 
incomplete programs. In particular, to allow processors to generated 
missing subclasses and even superclasses of the the initial set of sources.

In general, it is impractical to describe exactly how a compiler should 
model an incorrect program. The JSR 269 expert group took some some 
pains to craft a specification would balance the need for predictability 
while also allowing some room for implementation-specific behavior: 
current version of this specification with some refinements [1] over the 
years:

> During annotation processing, operating on incomplete or erroneous 
> programs is necessary; however, there are fewer guarantees about the 
> nature of the resulting model. If the source code is not syntactically 
> well-formed or has some other irrecoverable error that could not be 
> removed by the generation of new types, a model may or may not be 
> provided as a quality of implementation issue. If a program is 
> syntactically valid but erroneous in some other fashion, any returned 
> model must have no less information than if all the method bodies in 
> the program were replaced by "throw new RuntimeException();". If a 
> program refers to a missing type XYZ, the returned model must contain 
> no less information than if the declaration of type XYZ were assumed 
> to be "class XYZ {}", "interface XYZ {}", "enum XYZ {}", or 
> "@interface XYZ {}". If a program refers to a missing type XYZ<K1, ... 
> ,Kn>, the returned model must contain no less information than if the 
> declaration of XYZ were assumed to be "class XYZ<T1, ... ,Tn> {}" or 
> "interface XYZ<T1, ... ,Tn> {}"
http://docs.oracle.com/javase/8/docs/api/javax/lang/model/element/package-summary.html

As Jon alluded to earlier in this thread, how javac implements this 
aspect of the spec has evolved over time with the current intention to 
forge ahead when generating a missing type could allow the whole set of 
sources to compile successfully.

Cheers,

-Joe

[1] https://bugs.openjdk.java.net/browse/JDK-7003550
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160219/18ddf094/attachment.html>