Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8046110

JEP 120: Repeating Annotations

    XMLWordPrintable

    Details

    • Type: JEP
    • Status: Closed
    • Priority: P4
    • Resolution: Delivered
    • Fix Version/s: 8
    • Component/s: specification
    • Labels:
      None
    • Author:
      Joseph D. Darcy
    • JEP Type:
      Feature
    • Exposure:
      Open
    • Subcomponent:
    • Scope:
      SE
    • JSR:
      269 MR, 337
    • Discussion:
      enhanced dash metadata dash spec dash discuss at openjdk dot java dot net
    • Effort:
      S
    • Duration:
      M
    • Alert Status:
       Green
    • JEP Number:
      120

      Description

      Summary

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

      Goals

      Improve the readability of source code which logically applies multiple instances of the same annotation type to a given program element.

      Motivation

      Frequently-used idioms of programming with annotations in EE and elsewhere awkwardly use a container annotation just to simulate the ability to apply multiple annotations. Building in support for repeated annotations will improve the readability of source code.

      Description

      The basic approach to implement the language feature is to desugar repeated annotations of a base type into a single container annotation; the container annotation has a values method which returns an array of the base annotation type. For repeated annotations to be enabled for a particular annotation type, the declaration of the base annotation type will need to include a new meta-annotation, say @ContainerAnnotation, to declare which other annotation type should be used as a container. Warnings and errors should be issued if the container is not suitability compatible with the base annotation, including problematic differences in retention policy or target.

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

      @A(1)
      @A(2)
      @AContainer
      @AContainerContainer
      foo();

      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
      @AContainerContainer
      foo();

      At a libraries level, the implementations of the reflective APIs in the platform, including core reflection and javax.lang.model, will need to be updated to handle the repeated annotation information. For example, the AnnotatedElement.getAnnotation(BaseAnnotation.class) method will be redefined to look for in a container annotation if the base annotation is not directly present. One or more methods to query for the presence of absence of annotations may be added to the AnnotatedElement interface. If multiple levels of compiler-generated nesting is supported, the library changes will be more extensive.

      Testing

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

      Risks and Assumptions

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

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

      If the various Java IDEs do not support this language change during development, experimentation with the feature and validation of its design will be slowed.

      Dependences

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

      Impact

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

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

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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              mtrudeau Michel Trudeau
              Reporter:
              darcy Joe Darcy
              Owner:
              Alex Buckley Alex Buckley
              Endorsed By:
              Brian Goetz
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: