RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v2]

Joe Darcy darcy at openjdk.java.net
Wed Sep 23 02:35:23 UTC 2020


On Thu, 17 Sep 2020 17:59:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements
>> across all modules in the module graph, and only return a value when they find exactly one element. This is
>> troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from
>> any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that
>> these unqualified methods would first look for elements visible from the root modules, and would search the internals
>> of other modules only if nothing would be found in the first round.  The draft of the corresponding CSR is here:
>> https://bugs.openjdk.java.net/browse/JDK-8253168.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 62:

> 60:      *     <li>find non-empty packages with the given name returned by
> 61:      *         {@link #getPackageElement(ModuleElement, CharSequence)},
> 62:      *         where the provided ModuleSymbol is any root module,

Does "root module" mean one of the modules in the result of Elements.getAllModuleElements? If so, I suggest making
"root module" a link to the method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/200


More information about the compiler-dev mailing list