Repeating Annotations and backwards compatibility

[Alex Buckley]

I thought I made it clear that container annotations are required in 
the ClassFile for legacy users of reflection. We generate container 
annotations on an occurrence of repeating annotations precisely for 
their benefit. New users of reflection can use new methods which "look 
through" container annotations, but the container annotations are still 
physically present.

Alex

On Thursday, September 13, 2012 1:52:17 PM, Paul Benedict wrote:
> Alex,
>
> Does this mean that future specs will no longer strive to create new
> container annotations? Presumably with repeating annotations,
> container annotations are no longer a necessary design feature.
>
> Paul
>
> On Thu, Sep 13, 2012 at 2:00 PM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     On Thursday, September 13, 2012 9:04:39 AM, Paul Benedict wrote:
>
>         Was there any consideration given to NOT retrofitting
>         annotations? That is,
>         just allow repeating annotations; those with historical grouping
>         annotations have to retain them to maintain the same
>         reflection results.
>         Then no "looking through" magic needs to occur at the
>         reflection level. I
>         think that's much more straight-forward than what's being
>         proposed.
>
>
>     The goal was to be able to write repeating annotations without
>     writing the container annotation manually, and still have legacy
>     consumers work without modification when they a) expect a
>     container annotation from getAnnotation(Class<T>) and b) do not
>     expect repeating annotations from get[Declared]Annotations(). The
>     Java EE group believes the number of these legacy consumers to be
>     significant.
>
>     New consumers which use the new
>     get[Declared]Annotations(__Class<T>) methods can choose to ignore
>     container annotations and grab the possibly-repeated annotations
>     directly.
>
>     Alex
>
>