JEP 120: Repeating Annotations

Joe Darcy joe.darcy at
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:
> 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.


More information about the compiler-dev mailing list