JDK-8261263: Simplify javadoc link code

[hns]

This is a cleanup of the javadoc link generating code.

There is a simple "horizontal" component to this change that removes the strong parameters from most HtmlDocletWriter#getDocLink methods which where the value used was always false, and related changes in all the code using these methods.

The slightly more complex part of this change are changes in LinkInfo[Impl] and LinkFactory[Impl]. Here the target was to reduce the number of booean fields in LinkInfo and their interaction with the code, which was quite hard to grasp. I managed to replace several fields controlling generation of type parameter links with a single includeTypeParameterLinks() method. The use of this method and the remaining boolean fields in the code is quite straightforward.

I also removed some bits of dead code and simplified the control flow a bit by trying to do things only in one place and one way when possible.

The code passes all javadoc tests and generates documentation identical to the old code.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8261263: Simplify javadoc link code

Reviewers

• Jonathan Gibbons (@jonathan-gibbons - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2437/head:pull/2437
$ git checkout pull/2437

[bridgekeeper]

👋 Welcome back hannesw! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@hns The following label will be automatically applied to this pull request:

• javadoc

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (fb7f07d)

[jonathan-gibbons]

A couple of places where there are remnants of isStrong; are they still required?

[jonathan-gibbons]

This is pervasively disappearing elsewhere. Is it still needed here?

[jonathan-gibbons]

isStrong again

[jonathan-gibbons]

I see that isStrong is still used, but eventually maps into a style of typeNameLink down in the Links class, line 188. I believe the name strong refers back to using the HTML <strong> element, which no longer exists.

Can we now or soon change the name or at least the doc comments for this parameter into something more meaningful?

[openjdk]

@hns This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8261263: Simplify javadoc link code

Reviewed-by: jjg

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 33 new commits pushed to the master branch:

• 5183d8a: 8260355: AArch64: deoptimization stub should save vector registers
• 5d8204b: 8261368: The new TestNullSetColor test is placed in the wrong group
• f03e839: 8261127: Cleanup THREAD/TRAPS/CHECK usage in CDS code
• 7451962: 8129776: The optimized Stream returned from Files.lines should unmap the mapped byte buffer (if created) when closed
• ad525bc: 8261281: Linking jdk.jpackage fails for linux aarch32 builds after 8254702
• 2fd8ed0: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math
• ace8f94: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed
• ab65d53: 8261261: The version extra fields needs to be overridable in jib-profiles.js
• 20d7713: 8261334: NMT: tuning statistic shows incorrect hash distribution
• 92c6e6d: 8261254: Initialize charset mapping data lazily
• ... and 23 more: https://git.openjdk.java.net/jdk/compare/7a6c176845a0ae94faee411009e9fe2e2d74cdaa...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[jonathan-gibbons]

Updated review to Approved, but I hope we can do something now or soon to clean up the remaining use of isStrong. Either eliminate it or rename to something more appropriate.

[hns]

/integrate

[openjdk]

@hns Since your change was applied there have been 34 commits pushed to the master branch:

• 8ebed28: 8261237: remove isClassPathAttributePresent method
• 5183d8a: 8260355: AArch64: deoptimization stub should save vector registers
• 5d8204b: 8261368: The new TestNullSetColor test is placed in the wrong group
• f03e839: 8261127: Cleanup THREAD/TRAPS/CHECK usage in CDS code
• 7451962: 8129776: The optimized Stream returned from Files.lines should unmap the mapped byte buffer (if created) when closed
• ad525bc: 8261281: Linking jdk.jpackage fails for linux aarch32 builds after 8254702
• 2fd8ed0: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math
• ace8f94: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed
• ab65d53: 8261261: The version extra fields needs to be overridable in jib-profiles.js
• 20d7713: 8261334: NMT: tuning statistic shows incorrect hash distribution
• ... and 24 more: https://git.openjdk.java.net/jdk/compare/7a6c176845a0ae94faee411009e9fe2e2d74cdaa...master

Your commit was automatically rebased without conflicts.

Pushed as commit b0e7e5a.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.