RFR: 8284315: DocTrees.getElement is inconsistent with Elements.getTypeElement
Hannes Wallnöfer
hannesw at openjdk.org
Thu Feb 26 17:21:24 UTC 2026
On Thu, 26 Feb 2026 16:16:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:
>> Please review a change that brings the implementation of `DocTrees.getElement(DocTreePath)` in agreement with `javax.lang.model` behavior by returning `null` for `DocTree` instances referring to a primitive or array type. Additionally, this adds some missing functionality to the implementation of the related `DocTrees.getType(DocTreePath)` method and improves test coverage for both methods.
>>
>> Internally, the member lookup part in method `JavacTrees.attributeDocReference` is split into a separate `resolveMember` method that can also be used by `getType`.
>>
>> We also improve attribution of references with explicit module name by attempting to attribute the referenced type and checking whether the module matches the name in the reference afterwards. This allows us to support parameterized types in references with explicit module id.
>>
>> In `test/langtools/tools/javac/doctree/ReferenceTest.java` we add some missing test coverage such as for type parameter references, and add tests for `DocTrees.getType(DocTreePath)` to the existing tests for `DocTrees.getElement(DocTreePath)`. The former was previously ony covered in javadoc tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 518:
>
>> 516: }
>> 517:
>> 518: ClassSymbol sym = (ClassSymbol) types.skipTypeVars(type, false).tsym;
>
> I could be wrong but this `types.skipTypeVars` invocation should be unnecessary. `tsym` should always be the erased version. I have found another instance of this pattern in javadoc which probably can be removed too
You are right for the common case where `type` is a parameterized class. But `type` could itself be a type variable, in which case we need to convert it to a class for the member lookup. I'm adding a comment to make the purpose of this clear.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29547#discussion_r2860314136
More information about the javadoc-dev
mailing list