• Type: Bug
• Component: core-libs
• Sub-Component: javax.lang.model
• Affected Version: 9

• Priority: P3
• Status: Resolved
• Resolution: Fixed
• OS: generic
• CPU: generic

• Submitted: 2016-08-05
• Updated: 2021-04-07
• Resolved: 2016-12-16

JDK 9
9 b150Fixed

Specification changes out for review: http://cr.openjdk.java.net/~darcy/8163315.0/ 19-08-2016 Right, separate methods are needed for elements and annotation mirrors. My previous comment was that the annotation mirror overload may also need additional argument to provide context, i.e. boolean Elements.isMandated(Element, AnnotationMirror) or more generally boolean Elements.isMandated(AnnotatedConstruct, AnnotationMirror) 12-08-2016 boolean Elements.isMandated(Element) would not cover the case where the declaration is explicit but the container annotation is implicitly declared. We need a method that works on AnnotationMirrors. i.e. given your comment, that would mean boolean Elements.isMandated(Element, AnnotationMirror) 12-08-2016 I think a boolean Elements.isMandated(Element) method would be fine and consistent with the rest of the API. In the messaging API, we had to use the overloads printMessage(Diagnostic.Kind kind, CharSequence msg, Element e, AnnotationMirror a) printMessage(Diagnostic.Kind kind, CharSequence msg, Element e, AnnotationMirror a, AnnotationValue v) since the AnnotationMirror doesn't necessarily have backpointers to where it came from so similar "extra" arguments may be needed in this case. 12-08-2016 That's why we would like a method in jx.l.m. Suggest: boolean Elements.isMandated(AnnotationMirror) boolean Elements.isMandated(Element) 12-08-2016 This bug is related to the earlier bug JDK-8003654: "javadoc needs to determine if an annotation is explicitly present in the tree for repeating annotations." Ideally, the javadoc output for annotations would closely resemble the original source. In particular, the container annotation would be elided if it was compiler-generated. 12-08-2016 For some more context, from the package javadoc for javax.lang.model.element: "When used in the context of annotation processing, an accurate model of the element being represented must be returned. As this is a language model, the source code provides the fiducial (reference) representation of the construct in question rather than a representation in an executable output like a class file. Executable output may serve as the basis for creating a modeling element. However, the process of translating source code to executable output may not permit recovering some aspects of the source code representation. For example, annotations with source retention cannot be recovered from class files and class files might not be able to provide source position information. Names of parameters may not be recoverable from class files. The modifiers on an element may differ in some cases including: * strictfp on a class or interface * final on a parameter * protected, private, and static on classes and interfaces Additionally, synthetic constructs in a class file, such as accessor methods used in implementing nested classes and bridge methods used in implementing covariant returns, are translation artifacts outside of this model. " We could certainly add mandate-ness to the list of properties that could differ between source code based vs class file based generation of elements. 12-08-2016 The description of isSynthesized is effectively empty. Arguably, "mandated" is a more appropriate term than "synthetic", but either way it is not in the class file. The use case is container annotations for repeated annotations. 06-08-2016