getAnnotationsByType() in the presence of both repeating and container

[Alex Buckley]

On 3/20/2013 11:35 PM, Joe Darcy wrote:
> On 03/20/2013 12:58 PM, Alex Buckley wrote:
>> 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.

This is basically taken care of by the "present" rule which builds on 
"directly present".

If you have a simple case of inheritance:

@Foo(0) @FooContainer({@Foo(1), at Foo(2)}) class A {}
                                          class B extends A {}

then B.class.getAnnotationsByType(Foo.class) will return the "present" 
annotations on B, which reduce to the "directly present" annotations on 
A, which is a previously solved problem.

The policy of subclass annotations overriding superclass annotations 
means that ordering across the class hierarchy should never be an issue. 
So if you have a complex case of inheritance:

@Foo(0)                                  class A {}
@FooContainer({@Foo(1), at Foo(2)}) @Foo(3) class B extends A {}

then B.class.getAnnotationsByType(Foo.class) should consider only the 
@Foo's present on B, whose order is a previously solved problem.

Alex

P.S. I realized that the definition of "present":

- An annotation A is present on an element E if either:
   - A is directly present on E; or
   - A is not directly present on E, and E is a class, ...

is wrong because it makes @Foo(0) on A be present on B - but B's own 
@Foo's are meant to take precedence. The second clause was meant to be 
about a broad class of things, not a specific thing:

- An annotation A is present on an element E if either:
   - A is directly present on E; or
   - No annotation of A's type is directly present on E, and E is a 
class, ...

I'm pretty sure this latter definition is what got implemented, because 
examples 1.2-4 and 1.2-5 in the spec do the right thing and have been 
tested on the RI.