repeating annotations comments

[Remi Forax]

On 12/17/2012 06:25 PM, Joel Borggrén-Franck wrote:
> Hi,
>
> Paul and Remi, have you read the end of Alex' mail? When I read your mails I have a hard time figuring out if you noticed this idea and think even this is to much magic, if if you just missed it.

Hi Joel,
no, I've read the whole message :)

I think that Alex's proposal goes is the right way but I also think that 
container annotations doesn't worth to have new calls like 
get[Declared]Annotations(Class), as I said, I prefer the non magical way.
In my mind, container annotations are, as Paul said just syntactic sugar 
for framework users, and are seen by reflection as container annotations.

cheers,
Rémi

> On Dec 17, 2012, at 5:06 PM, Paul Benedict <pbenedict at apache.org> wrote:
>
>> If you look back in previous discussions, some have opined how they
>> don't want incongruity between the reflection data and the developer's
>> code. For example, if the code has @A @A, then two annotations should
>> be returned (except for legacy reflection methods). I think this
>> sentiment should fly out the window. Container annotations are
>> mandatory forever. They aren't going away ever -- so why hide them? I
>> definitely value all the work that has gone into this enhancement so
>> far, but perhaps there can be some 20/20 hindsight and see the
>> complexities getting a bit too deep.
>>
>> Is there any chance for the EG to consider this as syntactic sugar only?
>>
>>>>> Here's an idea. We pondered having the "existing" methods -
>>>>> get[Declared]Annotation(Class<T>) and get[Declared]Annotations() - be
>>>>> unaware of official containers, so they would return exactly what's in
>>>>> the
>>>>> class file. Essentially this is perfect behavioral compatibility.
>>>>> Meanwhile,
>>>>> the new get[Declared]Annotations(Class<T>) methods would look through
>>>>> official containers if present. How does that grab you?
>>>>>
> cheers
> /Joel
>