Musings on JDK development
-
Annotation Processing
March 14, 2011
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
Filerand rounds.Constructors explicitly added to the kinds of elements that can
be returned byRoundEnvironment.getElementsAnnotatedWith.New enum constant
javax.lang.model.SourceVersion.RELEASE_7.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
errors.New exception type
javax.lang.model.UnknownEntityExceptionadded as a common
superclass for existing exception typesUnknownAnnotationValueException,UnknownElementException, andUnknownTypeException.New enum constant
javax.lang.model.element.ElementKind.RESOURCE_VARIABLE.New mixin interfaces
ParameterizableandQualifiedNameableadded to packagejavax.lang.model.element.ExecutableElementandTypeElementare
retrofitted to extendParameterizable;PackageElementandTypeElementare
retrofitted to extendQualifiedNameable.Behavior of
getEnclosingElementmethod defined to
return the generic element of a type parameter instead ofnull.New interface
javax.lang.model.type.DisjunctiveTypeto model
disjunctive types.New enum constant
javax.lang.model.type.TypeKind.DISJUNCTIVEto mark
disjunctive types.New method
visitDisjunctiveadded to visitor
interfacejavax.lang.model.type.TypeVisitor.
Utility visitor implementations updated accordingly.In the package
javax.lang.model.type,MirroredTypesExceptionretrofitted to be the
superclass ofMirroredTypeException.New utility visitors for release 7 in package
javax.lang.model.util:AbstractAnnotationValueVisitor7AbstractElementVisitor7AbstractTypeVisitor7ElementKindVisitor7ElementScanner7SimpleAnnotationValueVisitor7SimpleElementVisitor7SimpleTypeVisitor7TypeKindVisitor7
The visitors
ElementKindVisitor6,ElementScanner6, andSimpleElementVisitor6,
are updated to account for new element kindRESOURCE_VARIABLE.The visitor
AbstractTypeVisitor6is updated to
account for the possibility of visiting aDisjunctiveType.Definition of documentation comment added to javadoc of
javax.lang.model.util.Elements.getDocComment.
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?
@Paul,
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.)