getAnnotationsByType() in the presence of both repeating and container

[Joe Darcy]

On 03/20/2013 12:58 PM, Alex Buckley wrote:
> On 3/20/2013 7:02 AM, Joel Borggrén-Franck wrote:
>> Alex pointed out to me that this is currently not according to spec,
>> because:
>>
>>> getAnnotationsByType(Class) relies on the definition of "present",
>>> which in turn relies on "directly present", which is:
>>>
>>> "An annotation A is directly present on an element E if ... for an
>>> invocation of get[Declared]AnnotationsByType(Class<T>), the
>>> attribute either contains A or, if the type of A is repeatable,
>>> contains exactly one annotation whose value element contains A and
>>> whose type is the containing annotation type of A's type (§9.6)."
>>>
>>> The either-or in this text does not really admit the merging of
>>> naked and contained @Foo's.
>
> Sorry, I read my own words wrong. The definition makes an @Foo 
> annotation be directly present whether it's naked or contained. So, 
> merging is supported already. However, nothing is said about ordering.
>
> While what we want is obvious from examples, it's a bit tricky to 
> define it without spelling out possible combinations of annotations. I 
> think the following text should appear in the AnnotatedElement javadoc 
> after the definitions of "directly present" and "present":
>
> -- 
> For an invocation of get[Declared]AnnotationsByType(Class<T>), the 
> order of directly present annotations on an element E is computed as 
> if annotations stored in a container annotation on E are stored on E 
> itself, in the order in which they appear in the value element of the 
> container annotation.
> -- 
>
> This will work for the language model definitions too - just change 
> "element E" to "construct C" in the javadoc for AnnotatedConstruct.
>
>

The ordering of inherited annotations should be explicitly specified too.

-Joe