Using error-types in annotation processors

Jonathan Gibbons jonathan.gibbons at oracle.com
Mon Nov 30 21:43:50 UTC 2015


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...
>
> Example1
> --------------
>      class MyClass extends MyClassToGenerate {
>      }
>
> Example2
> --------------
>      class MyClass extends MyClassToGenerate<T> {
>      }
>
> Example3
> --------------
>      class MyClass {
>          void method1(MyClassToGenerate argument) {
>          }
>      }
>
> Example4
> --------------
>      class MyClass {
>          void method1(MyClassToGenerate<T> argument) {
>          }
>      }
>
> --
> Victor Nazarov



More information about the compiler-dev mailing list