Summary

Change the RoundEnvironment.getElementsAnnotatedWith family of methods to obey their specs to not scan the contents of a package or module by virtue of examining a package-info or module-info file, respectively.

Problem

The implementations of the RoundEnvironment.getElementsAnnotatedWith family of methods does not obey the specification for treatment of package-info and module-info files:

Elements in a package are not considered included simply because a package-info file for that package was created. Likewise, elements of a module are not considered included simply because a module-info file for that module was created.

The current implementation scans a package or module if a package-info or module-info files is among the root elements of a round.

Solution

Change the implementation to obey the specification. The straightforward portion of the implementation change is to have the scanner not scan the contents of package and modules. A second portion of the changes concerns handling of Class type tokens to indicate which annotations types to look for.

The getElementsAnnotatedWith methods with a java.lang.Class parameter need some way to bridge between the core reflection world and the compile-time reflection world of javax.lang.model. The way to do this is to construct a TypeElement for an annotation type corresponding to the Class object for the annotation type argument by mapping from the name of the annotation type to a type element via Elements.getTypeElement(name). The behavior of Elements.getTypeElement(name) was redefined in JDK 9 to account for modules since a name can correspond to multiple types post-modules. In addition, a two-argument form of Elements.getTypeElement(name) was added in 9 taking a module argument as well as a name. The revised implementation first tries the one-argument form of Elements.getTypeElement and if that is unsuccessful, fails over to the two-argument version trying using a module argument matching the name of the runtime module of the annotation Class token.

First attempting the one-argument form increasing behavioral compatibility with the pre-modules system. The two-phase approach is reasonable; however, the runtime and compile-time module arrangement may differ, including from the compiler operating in single-module mode (http://openjdk.java.net/jeps/261) treating types it compiles as being in the same named module even if one the class path outside of the module-inferred directory structure. The hazard of runtime vs compile-time differences in modules for annotation types is intrinsic to allowing the model-breaking convenience of using Class objects as tokens. Similar issues are present when using the AnnotatedConstruct methods taking a Class object.

Specification

No specification change.