[jdk17] RFR: JDK-8259499: Handling type arguments from outer classes for inner class in javadoc

Hannes Wallnöfer hannesw at openjdk.java.net
Fri Jul 9 15:28:57 UTC 2021


On Thu, 8 Jul 2021 20:35:41 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This change adds support for generating HTML links to the type arguments of enclosing classes when creating a link to an inner class. Previously, only a link to the inner class was created and the type arguments were even omitted from the link label.
>> 
>> The new feature to create separate links to the enclosing class and its type arguments is only activated if the enclosing class has type arguments. If the enclosing class is non-generic, the old behavior is preserved to create a single link to the inner class. The reason for this is that a dedicated link to the enclosing class itself provides little benefit, since it can be easily reached via the "Enclosing class" link of the inner class. Also, linking the enclosing type in absence of type arguments makes it hard to see that there are two links and easy to click on the wrong link by mistake.
>> 
>> On the other hand, for type arguments a separate link should be useful since it is often not a "nearby" type. It is also easier to detect the different links than for non-generic nested classes. I came to like this "mixed" solution best after trying several other approaches.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1082:
> 
>> 1080:             // Must be a class reference since refClass is not null and refMemName is null.
>> 1081:             if (labelContent.isEmpty()) {
>> 1082:                 if (seeText.contains("<")) {
> 
> Hmmm, string-based checks are generally something of a red-flag, as compared to more abstract methods on appropriate classes. And, this is a string operation on the output of  `CommentHelper.getText`. Is there a way that we have may this a more robust test ... for example introduce `CommentHelper.isGeneric(ReferenceTree)` or something like that?

I agree something like `CommentHelper.isGeneric(ReferenceTree)` would be preferable, but that method would have to iterate over enclosing types to find any generic types there, just like the `LinkInfo.linkEnclosingTypes(DeclaredType)` method I have added. So I wonder where a shared method for this could go if not to `Utils` (I shudder to think).

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

PR: https://git.openjdk.java.net/jdk17/pull/195


More information about the javadoc-dev mailing list