Invoking code generated by an annotation processor

Thu Mar 3 02:48:04 UTC 2016

@jonathan, is there any chance this will get fixed in a future release of
javac ? (7 &/or 8+, we actually don't really mind about java 7 on our side).

Thx in advance,
 Stephane

2016-02-19 19:50 GMT-08:00 Stéphane NICOLAS <steff.nicolas at gmail.com>:

> 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/20160302/f4d5f628/attachment.html>