Invoking code generated by an annotation processor
Joseph D. Darcy
joe.darcy at oracle.com
Sat Feb 20 00:15:23 UTC 2016
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>
More information about the compiler-dev
mailing list