Behavior of getAnnotationsByType for @FooContainer({})

[Andreas Lundblad]

On 10/11/2013 09:45 PM, Alex Buckley wrote:
> 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
>

Alex,

I agree that making containers as "transparent" as possible is a good 
idea. In this case however, I would argue that we should see through the 
container, but not through the empty list.

Take for instance the case where idiomatic containers are used, i.e. we have

@FooContainer({@Foo}) class A {}
@FooContainer({}) class B extends A {}

Here {} is bound to overwrite {@Foo}. If we say that @FooContainer({}) 
should be "ignored" (i.e. its presense should not prevent inheritence) 
some SE7 code may have troubles adopting the @Repeatable feature. If we, 
on the other hand, do take the empty list into consideration, the 
indirectly present annotations can still be inherited by simply leaving 
@FooContainer({}) out.

That being said, I have only worked with this for a week or so, so 
please forgive me if I've overlooked something.

-- Andreas