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