getAnnotationsByType() in the presence of both repeating and container

[Alex Buckley]

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.

Alex