getAnnotationsByType() in the presence of both repeating and container

[Alex Buckley]

In every case, the answer and reason is the same:

   @Foo(2) @Foo(3)  (in that order)

because while @Foo(0) and @Foo(1) are directly present on A, the fact 
that even one annotation of type Foo is directly present on B means that 
@Foo(0) and @Foo(1) are not present on B. (This is the overriding policy 
we always intended, and which is now correctly embodied by the "present" 
rule.)

Alex

On 3/21/2013 3:19 PM, Ali Ebrahimi wrote:
> Hi Alex,
> please clarify following scenarios:
>
> 1)
>
> @Foo(0)   @Foo(1)                               class A {}
> @Foo(2)   @Foo(3) class B extends A {}
>
> B.class.getAnnotationsByType(Foo.class)?
>
>
> 2)
> @FooContainer({@Foo(0), at Foo(1)}) class A {}
> @FooContainer({@Foo(2), at Foo(3)}) class B extends A {}
>
> B.class.getAnnotationsByType(Foo.class)?
>
>
> 3)
>
> @Foo(0)   @Foo(1)                               class A {}
> @FooContainer({@Foo(2), at Foo(3)}) class B extends A {}
>
> B.class.getAnnotationsByType(Foo.class)?
>
> 4)
> @FooContainer({@Foo(0), at Foo(1)}) class A {}
> @Foo(2)   @Foo(3) class B extends A {}
>
> B.class.getAnnotationsByType(Foo.class)?
>
>
> Regards,
> Ali Ebrahimi
> On Fri, Mar 22, 2013 at 2:24 AM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     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.
>
>