JEP 120: Repeating Annotations
Joe Darcy
joe.darcy at oracle.com
Thu Jan 5 12:20:08 PST 2012
Hi Jesse,
On 1/5/2012 11:49 AM, Jesse Glick wrote:
> On 11/01/2011 06:11 PM, mark.reinhold wrote:
>> Posted: http://openjdk.java.net/jeps/120
>
> This would be valuable indeed. Comments:
>
> 1. "the container annotation has a values method which returns an
> array of the base annotation type" is awkward since the language
> already defines a special implicit method name "value" (no 's'), which
> is what I think should be used.
Yes; that was a typo -- I meant for the existing built-in "value" method
to be used in the container. Thanks for catching that.
> Thus
>
> @Things({@Thing(1), @Thing(2)})
>
> could be replaced with
>
> @Thing(1) @Thing(2)
>
> 2. Rather than forcing a separate container annotation
>
> @ContainerAnnotation(Things.class)
> @interface Thing {int value();}
> @interface Things {Thing[] value();}
>
> you could just specify that the base annotation can repeat:
>
> @Repeatable
> @interface Thing {int value();}
>
> and introduce <T extends Annotation> List<? extends T>
> AnnotatedElement.getAnnotations(Class<T>) and the like. (The singleton
> variants would just return one of the annotations if more than one
> were present.) This would seem more intuitive to me, and obviate
> various open design issues.
>
It would obviate some design issues while opening up many others, such
as how the repeated annotations are represented in a class file.
The approach proposed in the JEP largely reduces to a previously solved
case and does not require any modifications at the JVM-level, only in
the compiler and the core library code. Additionally, the existing work
arounds for the absence of repeated annotations can be smoothly migrated
to use the new language idiom.
-Joe
More information about the compiler-dev
mailing list