Behavior of getAnnotationsByType for @FooContainer({})

[Alex Buckley]

Hi Andreas,

In Java SE 7, an @Foo on class A is visible on class B - class B "bought 
in" to that policy when it subclassed A. And so, in SE 7, the only way 
to "prevent" A's @Foo from being visible on B is for B to have a 
directly-present @Foo. That doesn't change in SE 8 - we just allow B to 
have one @Foo (directly-present) or many (indirectly-present).

More generally, as a general principle, a thing is inherited unless 
overridden by a thing of the same name. And so, for the new 
get[Declared]AnnotationsByType methods in AnnotatedElement, we try hard 
to "look through" the container annotation and reason solely about 
annotations of the type which the user actually queried (Foo.class). In 
this model, it's undesirable to say that @FooContainer on B overrides 
@Foo on A.

Alex

On 10/11/2013 12:25 AM, Andreas Lundblad wrote:
> The question is how B.class.getAnnotationsByType(Foo.class) should
> behave in the presence of:
>
> @Inherited
> @interface FooContainer {
>       Foo[] value();
> }
>
> @Inherited
> @Repeated(FooContainer.class)
> @interface Foo {}
>
> @Foo class A {}
> @FooContainer({}) class B {}
>
>
> It is indeed quite similar to Example 1.2-4, except that in this case
> the FooContainer is empty. Strictly speaking this causes the second
> condition of the associated-definition to hold:
>
> "No annotation of Foo's type is directly or indirectly present on B, and
> B is a class, and Foo's type is inheritable, and Foo is associated with
> the superclass of B."
>
> This is, to me at least, a bit counter intuitive (and it prevents a user
> from explicitly saying "this subclass should not inherit any
> Foo-annotations" without adding at least one new Foo-annotation on the
> subclass).
>
> -- Andreas