Invoking code generated by an annotation processor

Sat Feb 20 03:50:28 UTC 2016

Thx Joe for this historical precision, I appreciate it.

I read carefully, and when the specs says :

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.

In the 2 cases we highlighted : a static import error or an erroneous
annotation value, it's hard to say here if a source with those errors is
syntactically valid.

*If we consider it syntactically valid : *then those errors are not
recoverable, as they prevent the annotation processor from running. So
those errors should be reported. And javac does that. But it also reports
all cals to generated code as errors, which is our concern.

Later, the specs says :

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();"

Here, javac seems to fail in our case as the source code is syntactically
valid, but erroneous in some other fashion, but our generated code is not
assumed to have the form of empty classes, methods etc.. The annotation
processor is simply not run and those errors are reported.

So, if such errors are not considered syntax errors, javac doesn't follow
the specs.

*If we consider the program is not syntactically valid : *then we fall in a
loophole of fuzzyness of the specs : a model may or may not be provided as
a quality of implementation issue. It looks like it's not possible to
generate a model that could be passed to annotation processors because of
those errors. Then only those should be reported.

I tend to think there is something missing on this matter in the specs you
mention : an intermediary class of error.

Unrecoverable errors :

   - syntax errors are about the form of the program (missing commas,
   braces, etc. name it). Those are reported well by javac, and only them are
   reported. Perfect
   - model building errors : static imports and annotation values errors.
   Those are also reported well by javac but they drag along with them error
   to generated code, the recoverable errors below.

Recoverable errors :

   - unknown classes or members of known classes : those are not considered
   as error before annotation processing takes place. Which is OK, but they
   are reported in case of model building errors, which is our concern.

So we can say here, to summarize the problem differently that right after
parsing a source and considering it valid, javac open a list of errors it
finds in the source. It adds all recoverable errors it finds to save them
for a next phase of processing after annotation processing. But at that
very precise moment, it also adds to the error list the non recoverable
model building errors. And if one is found, then all errors are reported,
which is not correct.

The solution would be to separate model building errors and recoverable
errors right after having considered a program syntactically valid.
Maybe there is an intermediary phase needed to identify strictly non
recoverable model building errors and list them, before building the model
and detecting recoverable errors, which javac handles well.

S.

2016-02-19 16:15 GMT-08:00 Joseph D. Darcy <joe.darcy at oracle.com>:

> 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/1c7a2c5a/attachment.html>