getAnnotationsByType() in the presence of both repeating and container

[Alex Buckley]

Both cases are illegal because:

It is a compile-time error if a declaration is annotated with more than 
one annotation of a repeatable annotation type T and any annotations of 
the containing annotation type of T.

The reason is exhaustively discussed in section 9.7 of the spec.

Alex

On 3/21/2013 3:31 PM, Ali Ebrahimi wrote:
> Hi again Alex,
> and this scenarios:
>
> 5)
>
> @Foo(0)   @Foo(1)   @FooContainer({@Foo(01), at Foo(11)
> }) class A {}
> @Foo(2)   @Foo(3) class B extends A {}
>
> B.class.getAnnotationsByType(Foo.class)?
>
>
> 6)
> @FooContainer({@Foo(0), at Foo(1)}) class A {}
> @Foo(02)   @Foo(03) @FooContainer({@Foo(2), at 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.
>
>
>