Accessing type annotations via annotation processor

[Gunnar Morling]

Hi,

2014-08-19 2:40 GMT+02:00 Joe Darcy <joe.darcy at oracle.com>:

>  Hello,
>
>
> On 08/15/2014 03:53 AM, Gunnar Morling wrote:
>
>  Hi,
>
>  2014- 8-14 19:25 GMT+02:00 Joe Darcy <joe.darcy at oracle.com>:
>
>>  Hello,
>>
>>
>> On 08/13/2014 11:56 PM, Gunnar Morling wrote:
>>
>> Hi Alex,
>>
>> 2014-08-11 20:13 GMT+02:00 Alex Buckley <alex.buckley at oracle.com>:
>>
>>> There are some known problems with retrieving type annotations on type
>>> parameter declarations, in both the Core Reflection API and the Language
>>> Model API. I believe type annotations on types used in member declarations
>>> work OK. If you have the VariableElement for 'values', you can get the
>>> TypeMirror for 'List<@NotNull String>', then visit it as a DeclaredType and
>>> call getTypeArguments() to get a TypeMirror for '@NotNull String'.
>>> TypeMirror is an AnnotatedConstruct so it can return the annotations on the
>>> use of 'String'.
>>
>>
>>  I tried what you suggested, but I only obtained a TypeMirror for
>> 'List<String>' from the VariableElement, thus the TypeMirror for the type
>> argument represents 'String' rather than '@NotNull String'. Is there any
>> example or test in OpenJDK which shows the retrieval of type annotations
>> via the Language Model API?
>>
>>
>>  Since the AnnotatedConstruct interface is now implemented by both
>> elements and type mirrors, is *should* work go call the annotation
>> retrieval methods on a TypeMirror.
>>
>>
>>
>>  Another issue is that the process() method of the annotation processor
>> is never invoked for the @NotNull annotation if it is only used as type
>> annotation (the processor will be invoked though if @NotNull is e.g. used
>> as a traditional field-level annotation). Is this an expected behavior?
>>
>>
>>  From the revised discovery process documented in
>> javax.annotation.processing.Processor:
>>
>> "Annotations on  type uses, as opposed to annotations on elements, are
>> ignored when computing whether or not an annotation type is present."
>>
>
>  Ah, I see. Thanks for the pointer.
>
>  Are there any plans to remove this restriction?
>
>
> No; that was a conscious design decision. Type annotation are relatively
> uncommon and we thought it would be a poor trade-off to require much more
> extensive scanning of sources to look for annotations in those positions.
>

I understand. At some point it might make sense to have some sort of switch
which enables the discovery of type annotations (e.g. a processor could
declare that it needs to handle type annotations). But what you describe
below should work for me atm.

>   Our annotation processor for Bean Validation aims at detecting
> constraint declaration errors such as "List<@Email Integer> email"
> (applying the @Email constraint to Integers does not make sense), but as it
> stands its not possible to implement such check for type annotations atm.
>
>
> To implement this functional, you could declare an annotation processor to
> process "*" and then do your own scans for the annotations of interest.
>

Ah, yes. I somehow assumed that an annotation processor would only ever be
invoked if there is at least one annotation present; but when processing
"*" I indeed see completely un-annotated root elements via RoundEnvironment
#getRootElements().

>
> HTH,
>
> -Joe
>

Many thanks for your help,

--Gunnar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140819/9184d7b4/attachment-0001.html>