Using error-types in annotation processors

[Joseph D. Darcy]

Hello,

On 11/30/2015 1:43 PM, Jonathan Gibbons wrote:
> cc: compiler-dev
> bcc: anno-pipeline-dev
>
> That being said, it seems like this is a bug/rfe that should be filed 
> and fixed.
>
> -- Jon
>
>
> On 11/27/2015 05:36 AM, Victor Nazarov wrote:
>> Hello,
>>
>> I hope that this is an appropriate place to write my question.
>>
>> To add some context, I'm a developer of [adt4j](
>> https://github.com/sviperll/adt4j) project.
>>
>> Java compiler pass every reference to unknown classes as an "error" 
>> type.
>> But it can be useful to inspect such error-types in annotation 
>> processor to
>> actually generate missing classes. This somewhat works in latest 
>> JDK8, but
>> not in the special case interesting for adt4j project.
>>
>> The way to inspect error type is to use methods provided by
>> ErrorType-class. There are only two interesting ways to inspect error 
>> type:
>>
>> errorType.asElement().getSimpleName() --- to get the name of missing 
>> class
>> errorType.getTypeArguments() --- to get type-arguments applied to
>> type-to-be.
>>
>> The problem is that sometimes these methods provide no useful 
>> information.
>> In such situation getSimpleName method returns useless "<any>" string 
>> and
>> no feather processing is possible.
>>
>> Suppose that we want to generate class MyClassToGenerate and it is
>> currently missing. Below are some code snippets. With Example1, Example2
>> and Example3 error-type processing works as expected. Example4 
>> doesn't work
>> as expected and always returns "<any>" string. This looks 
>> inconsistent and
>> I'd be glad if it can be fixed in future versions of Java...

[snip]

FYI, the behavior of the javax.lang.model.* objects in annotation 
procession in the presence of incomplete / incorrect programs was a 
challenging part of the specification. After much consideration, the 
text we ended up with was:

> 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

Cheers,

-Joe

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20151207/78d56e7e/attachment-0001.html>