Question for Mike re: changing containers

[Paul Benedict]

My armchair opinion here...

I would let the container annotation dictate what is inherited or not.
That's the "king" and what's contained is the "subject", so to speak.
Repeating annotations are just syntatic sugar -- they always get contained
regardless. Therefore, in terms of runtime, I propose that @Inherited on
@Foo is completely ignored. It should all be driven on the container.

Paul

On Thu, Mar 7, 2013 at 7:05 PM, Alex Buckley <alex.buckley at oracle.com>wrote:

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