Summary

Change the Java programming language to allow multiple applicationof annotations with the same type to a single program element.

Goals

Improve the readability of source code which logically appliesmultiple instances of the same annotation type to a given programelement.

Motivation

Frequently-used idioms of programming with annotations in EE andelsewhere awkwardly use a container annotation just to simulate theability to apply multiple annotations. Building in support forrepeated annotations will improve the readability of source code.

Description

The basic approach to implement the language feature is to desugarrepeated annotations of a base type into a single containerannotation; the container annotation has avalues method whichreturns an array of the base annotation type. For repeatedannotations to be enabled for a particular annotation type, thedeclaration of the base annotation type will need to include a newmeta-annotation, say@ContainerAnnotation, to declare which otherannotation type should be used as a container. Warnings and errorsshould be issued if the container is not suitability compatible withthe base annotation, including problematic differences in retentionpolicy or target.

Open design issues include whether or not multiple levels ofcompiler-generated containers will be supported. For example, should

@A(1)@A(2)@AContainer@AContainerContainerfoo();

be treated as logically equivalent to

@AContainerContainer(@AContainer({@A(1), @A2}), @AContainer)foo();

or a compilation error after one level of nesting to

@AContainer({@A(1), @A(2)})@AContainer@AContainerContainerfoo();

At a libraries level, the implementations of the reflective APIs inthe platform, including core reflection andjavax.lang.model, willneed to be updated to handle the repeated annotation information. Forexample, theAnnotatedElement.getAnnotation(BaseAnnotation.class)method will be redefined to look for in a container annotation if thebase annotation is not directly present. One or more methods to queryfor the presence of absence of annotations may be added to theAnnotatedElement interface. If multiple levels of compiler-generatednesting is supported, the library changes will be more extensive.

Testing

As with all language changes, the corresponding compiler JCK testswill need to be updated.

Risks and Assumptions

One risk is the possibility of currently unforeseen interactionsbetween this language feature and existing library semantics orbetween this language feature other language features present in JavaSE 8. In particular, the interaction, if any, between repeatedannotations and annotations on types will need to be defined.

An assumption is that existing EE annotation types which use themanual container annotation pattern will migrate to use the repeatingannotations pattern and thereby validate the feature through usage.

If the various Java IDEs do not support this language change duringdevelopment, experimentation with the feature and validation of itsdesign will be slowed.

Dependences

The interaction between repeating annotations andJEP 104: Annotations on Java Types, if any, needs to be defined.

Impact

• Other JDK components: Direct use of repeated annotations in theJDK code base is expected to be minimal.

• Compatibility: Interfaces not usually expected to haveimplementations outside of the JDK may have methods added to them.Defender methods from Project Lambda can help limit the sourcecompatibility impact.

• Performance/scalability: There should be no degradation incompilation speed if the feature is not used.