getAnnotationsByType() in the presence of both repeating and container

[Ali Ebrahimi]

Thanks.

On Fri, Mar 22, 2013 at 3:35 AM, Alex Buckley <alex.buckley at oracle.com>wrote:

> 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 <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.
>>
>>
>>
>>