A simpler model for repeating annotations

[Paul Benedict]

My suggestion here might be a case of over-engineering, but it's worth
a shot .. even if it is shot down. While today Java is being enhanced
for repeating annotations, more changes in the future might show up
that will make the new methods needing a replacement too. What about
an Enum for the kind of compatibility you're looking for?

getWhateverNameAnnotations(Class, Enum<AnnotationSourceFlags>);

For example, AnnotationSourceFlags could declare { CONTAINER_ONLY,
REPEATING } today with room for growth.

Paul

On Mon, Jan 7, 2013 at 12:55 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> On 1/7/2013 8:55 AM, michael keith wrote:
>>
>> Since the get[Declared]Annotations(Class) methods are semantically
>> different from the others they do deserve something different in their
>> names to indicate it. However, given that the javadoc of the lagacy
>> get[Declared]Annotations() methods state simply "Returns *all*
>> annotations [directly] present on this element" (emphasis added) I am
>> not sure that adding "All" to the semantically different
>> get[Declared]Annotations(Class) pair is going to be a very good
>> differentiator. Maybe "multiple" could be used in a different way, for
>> example: get[Declared]AnnotationsWithMultiples?
>
>
> We will in any case change the specs of legacy methods to avoid "all
> annotations". We will also say more about container annotation and
> look-through in the specs of new methods.
>
> With regard to names, an advantage of getAnnotationsWithMultiples(Class) is
> that it will appear after the legacy methods, which I think is better than
> appearing first like getAllAnnotations(Class). Stay tuned.
>
>> Also, I was just wondering if the getDeclaredAnnotation(Class) method
>> will be considered a backfilled "new legacy" method and have similar
>> semantics to getAnnotation(Class), or will it look through?
>
>
> The former. Per the PDF:
>
> "- Add getDeclaredAnnotation(Class<T>). The behavior is that of
> getAnnotation(Class<T>) but ignoring inherited annotations on classes. For
> simplicity, the added method is treated as an "SE 7 method" in the remainder
> of this document."
>
> Alex