Question for Mike re: changing containers

[Alex Buckley]

If you change:

   @Repeatable(FooContainer.class)
   @interface Foo {...}

to:

   @Repeatable(OtherContainer.class)
   @interface Foo {...}

then getAnnotationsByType(Foo.class) will seek out @OtherContainer. Any 
@FooContainer (generated by a compiler to wrap @Foo @Foo prior to the 
change) will be ignored. So, switching Foo's containing annotation type 
is behaviorally incompatible for reflective clients.

There is no way around that, but actually, it wasn't what I meant to ask 
you!

Suppose FooContainer is intended to be the containing annotation type 
for Foo forever. Do you ever tweak FooContainer's declaration, for 
example, expanding its applicability (adding entries to @Target) ?

I ask because Joel and I are wondering how strict to be in 
getAnnotationsByType(Class) if FooContainer diverges slightly from Foo's 
expectations. No doubt FooContainer will be a proper "containing 
annotation type" for Foo almost all the time, since you can't compile 
@Foo @Foo otherwise - but maybe someone makes a mistake, where 
@Inherited is removed from FooContainer but not Foo, and then @Foo @Foo 
isn't inherited because @FooContainer isn't inherited - this would cause 
a subtle change in client behavior. I think we're heading towards saying 
this is just "OK", rather than raising an AnnotationFormatError.

tl;dr There are many rules tying FooContainer to Foo, and maybe they 
just don't matter much at run-time.

Alex

On 3/6/2013 11:10 PM, michael keith wrote:
> Our usage of the container annotation has fairly consistently been a
> trivial mapping from the singular contained annotation to its pluralized
> containing form. We have, during development, changed the name of the
> singular annotation and then had to go and rename the container
> annotation to the plural form of the newly named singular one, but it
> would not be common at all to decide to rename the container one
> independent of the singular one, and I am talking about development,
> before clients exist.
>
> Existing clients of the current getAnnotation(Class) and
> getAnnotations() methods are written to reference both the repeatable
> and the container annotations directly, so renaming either one of them
> would be a breaking change that we would not generally undertake after
> the annotations have been created/released.
>
> I would not have expected a precompiled client of
> getAnnotationsByType(Foo.class) to be affected by such a change, though.
> The container annotation is meant to be transparent to them, isn't it?
>
> -Mike
>
> On 06/03/2013 8:22 PM, Alex Buckley wrote:
>> Mike, we're pondering whether the new methods in core reflection
>> should be strict about the relationship of containing type to
>> repeatable type.
>>
>> Have you ever written @FooContainer({@Foo(1),...}) on a declartion,
>> and later changed it to @OtherContainer({@Foo(1),...}) ? The effect on
>> clients using getAnnotation(Class) and getAnnotations() would be
>> significant.
>>
>> Effectively we are wondering if a client using
>> getAnnotationsByType(Foo.class) should be affected by such a change.
>>
>> Alex
>