8370154: Update @jls and @jvms taglets to point to local specs dir

[dansmithcode]

Updated the JSpec taglets to use relative links into ../specs/jls and ../specs/jvms rather than external links, possible now due to JDK-8370153.

I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.

Tested with 'make docs' and manually confirmed that a handful of different @jls and @jvms tags are pointing to the right place.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8370154: Update @jls and @jvms taglets to point to local specs dir (Enhancement - P4)

Reviewers

• Chen Liang (@liach - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/28207/head:pull/28207
$ git checkout pull/28207

Update a local copy of the PR:
$ git checkout pull/28207
$ git pull https://git.openjdk.org/jdk.git pull/28207/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28207

View PR using the GUI difftool:
$ git pr show -t 28207

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/28207.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back dlsmith! 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]

@dansmithcode 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:

8370154: Update @jls and @jvms taglets to point to local specs dir

Reviewed-by: liach

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 31 new commits pushed to the master branch:

• 76a1109: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out
• e1c9526: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space
• 43afce5: 8371573: Shenandoah: Remove unnecessary include after JDK-8351091
• ... and 28 more: https://git.openjdk.org/jdk/compare/2c3c4707c0ac7f4432ada9621f4b2e5fe4aef51f...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.

[openjdk]

@dansmithcode The following labels will be automatically applied to this pull request:

• build
• javadoc

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

[mlbridge]

Webrevs

• 02: Full - Incremental (cb8de969)
• 01: Full - Incremental (a47c3c5a)
• 00: Full (ec6d88dd)

[liach]

Looks goood. Meanwhile, do you think we should retain external link support via a system property? For the Java SE API specification only distribution for JCP, we might want to link to a static link instead of a local relative link. (I think as long as we can link, a relative link like here is better because it will be stable in the specdiff for JCP review, avoiding spams)

Since we removed the system property jspec.version, we should be able to remove this from the build files too:

jdk/make/Docs.gmk

Line 295 in 066810c

-Djspec.version=$$(VERSION_SPECIFICATION)

[dansmithcode]

JCP reviews actually happen before GA, so I think the external links are always dead anyway?

If it's something the JCP folks care about, I think the right solution is to include JLS & JVMS in the SE-only docs. (They are, after all, specs for Java SE.) But for now, I think the business as usual process is fine.

[dansmithcode]

I'll confirm there are no more uses of jspec.version and update Docs.gmk.

[liach]

I think we can go ahead with this once we verify Oracle's doc build passes. I will approve once the system property passing in Docs.gmk is updated.

[liach]

I tested this patch on my local Linux-targeting OpenJDK WSL (because only Linux is building docs); the JVMS links become dead links in OpenJDK builds, which don't have access to JLS/JVMS, which are proprietary to Oracle. We should probably leave a comment that the dead links are intentional.

[liach]

Verified this passes on Oracle's CI.

[dansmithcode]

I tested this patch on my local Linux-targeting OpenJDK WSL (because only Linux is building docs); the JVMS links become dead links in OpenJDK builds, which don't have access to JLS/JVMS, which are proprietary to Oracle. We should probably leave a comment that the dead links are intentional.

Where is a good place for that comment?

I do want to be careful not to "break" the functionality of make docs when building without the Oracle-internal content. But I think this is more of the same? E.g., ObjectInputStream has links to specs/serialization, which doesn't exist in an open build.

[dansmithcode]

/integrate

[openjdk]

Going to push as commit c6a8027.
Since your change was applied there have been 37 commits pushed to the master branch:

• f5eacbe: 8371534: C2: Missed Ideal optimization opportunity with AndL and URShiftL
• bbeb6bf: 8371493: Simplify search for AdapterHandlerEntry
• 405d5f7: 8371297: C2: assert triggered in BoolTest::BoolTest
• ... and 34 more: https://git.openjdk.org/jdk/compare/2c3c4707c0ac7f4432ada9621f4b2e5fe4aef51f...master

Your commit was automatically rebased without conflicts.

[openjdk]

@dansmithcode Pushed as commit c6a8027.

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