Musings on JDK development

JSR 269 Maintenance Review

As a planned part of Java SE 7, JSR 269, which standardized an API for annotation processing, is now undergoing maintenance review.
In the JCP, a maintenance review is a process to take comments on small changes so that those small changes can be formally incorporated into an existing specification without running a whole new JSR.
The changes being proposed in the JSR 269 maintenance review are the changes already implemented in the JSR 269 APIs in JDK 7.
In summary, those proposed changes are:

  • Clarified interaction between the Filer and rounds.

  • Constructors explicitly added to the kinds of elements that can
    be returned by RoundEnvironment.getElementsAnnotatedWith.

  • New enum constant

  • In the package description of
    javax.lang.model.element, requirements on when a model
    must be provided are loosened to remove the requirement in case of an
    "irrecoverable error that could not be removed by the generation of
    new types," a condition which includes but is not limited to syntax

  • New exception type
    javax.lang.model.UnknownEntityException added as a common
    superclass for existing exception types
    UnknownElementException, and

  • New enum constant

  • New mixin interfaces Parameterizable and
    QualifiedNameable added to package
    ExecutableElement and TypeElement are
    retrofitted to extend Parameterizable;
    PackageElementand TypeElement are
    retrofitted to extend QualifiedNameable.

  • Behavior of getEnclosingElement method defined to
    return the generic element of a type parameter instead of

  • New interface
    javax.lang.model.type.DisjunctiveType to model
    disjunctive types.

  • New enum constant
    javax.lang.model.type.TypeKind.DISJUNCTIVE to mark
    disjunctive types.

  • New method visitDisjunctive added to visitor
    interface javax.lang.model.type.TypeVisitor.
    Utility visitor implementations updated accordingly.

  • In the package javax.lang.model.type,
    MirroredTypesException retrofitted to be the
    superclass of MirroredTypeException.

  • New utility visitors for release 7 in package

    • AbstractAnnotationValueVisitor7

    • AbstractElementVisitor7

    • AbstractTypeVisitor7

    • ElementKindVisitor7

    • ElementScanner7

    • SimpleAnnotationValueVisitor7

    • SimpleElementVisitor7

    • SimpleTypeVisitor7

    • TypeKindVisitor7

  • The visitors ElementKindVisitor6,
    ElementScanner6, and SimpleElementVisitor6,
    are updated to account for new element kind

  • The visitor AbstractTypeVisitor6 is updated to
    account for the possibility of visiting a

  • Definition of documentation comment added to javadoc of

Join the discussion

Comments ( 2 )
  • Paul Tuesday, March 15, 2011

    Joe, it's not clear to me why the xxxScanner6/xxxVisitor6 classes need to be updated for RESOURCE_VARIABLE. Why would a resource variable be visible to a JDK 6 language model?

  • Joe Darcy Tuesday, March 15, 2011


    For a given JDK release, there is a single language model API that models language versions from JDK 5/6 forward. For JDK 7, the API in javax.lang.model.\* fully models the Java SE 7 features, including resource variables. If a JDK 6 era processor, compiled against the JDK 6 API, is run against JDK 7 and asked to process source code using new features, something sensible still needs to happen. That is why the xxxScanner6/xxxVisitor6 classes are updated to explicitly test for the JDK 7 features. (For resource variables in particular, a compiler-specific API needs to be used for a processor to see such structures, but it is still correct for the visitors to be updated.)

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.