8379344: Compact the Unicode/CLDR version tables

[naotoj]

Minor Javadoc fix to java.lang.Character and java.util.spi.LocaleServiceProvider, which list supported Unicode/CLDR versions. Since the tables grow with each JDK release, older releases should be coalesced.

---

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-8379344: Compact the Unicode/CLDR version tables (Enhancement - P4)

Reviewers

• Justin Lu (@justin-curtis-lu - Reviewer) Review applies to 939ebdab
• Alan Bateman (@AlanBateman - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 30099

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

8379344: Compact the Unicode/CLDR version tables

Reviewed-by: alanb, jlu

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

• d3158e7: 8379628: Refactor langtools/shellsupport/doc tests to use JUnit
• 680503c: 8378470: Add future Intel family number
• 5aa115b: 8379622: Problemlist java/nio/channels/SocketChannel/OpenLeak.java and CloseDuringConnect.java on macos 26
• ... and 86 more: https://git.openjdk.org/jdk/compare/c52d7b7cbc89548c3e9cd68a29ff0cec04888b09...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]

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

• core-libs
• i18n

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 (fe652029)
• 01: Full - Incremental (84ebdc0a)
• 00: Full (939ebdab)

[justin-curtis-lu]

The new tables look great. I think the JBS issue should be updated to say that the five-most recent releases are shown, rather than the LTS releases.

[naotoj]

I think the JBS issue should be updated to say that the five-most recent releases are shown, rather than the LTS releases.

Thanks. I forgot to update the JBS entry, as picking LTSes does not seem to be appropriate from the Java SE spec standpoint.

[liach]

I recommend you add a HTML comment that the non-collapsable table should show 5 entries. Otherwise the rule for hiding entries is confusing and the list may still explode over time.

[AlanBateman]

What would you think about adding a <p> element for the "Variations .." paragraph so that there is a bit of vertical space between "Show older Java releases" and this paragraph when collapsed.

[AlanBateman]

I recommend you add a HTML comment that the non-collapsable table should show 5 entries. Otherwise the rule for hiding entries is confusing and the list may still explode over time.

Or maybe it's not 5, maybe it's "interesting" versions. For CLDR it is interesting to see that JDK 21 used CLDR 43, JDK 25 used CLDR 47, this release is CDLR 48. JDK 21 has spilled into the older releases so you have to expand. For the Unicode table in Character, the Unicode 14.0 upgrade in Java 19 isn't too interesting, maybe that one should move to the older table.

(Going further, it might actually be useful to show the Unicode version for Java 21 even though it wasn't upgraded in that release. That avoids a reader needing to realize that it's the upgrades that are only shown when they really just want to see what Unicode version is in JDK $N release)

[naotoj]

(Going further, it might actually be useful to show the Unicode version for Java 21 even though it wasn't upgraded in that release. That avoids a reader needing to realize that it's the upgrades that are only shown when they really just want to see what Unicode version is in JDK $N release)

Initially I thought listing LTSes in the expanded list, and put others collapsed. Then I thought LTS is an Oracle thing and not Java SE spec (although it's de-facto), so I am kind of hesitant to list them (CLDR might be OK as it is JDK imp). Thus ended up to list the recent 5 releases. Do you think it is OK to put Oracle's LTSes in the expanded supported Unicode versions?

[naotoj]

OK, I reverted to list LTSes in the expanded table as they are LTSes in pretty much every distibution, and it does not make anything normative. Also, I changed the list in Character to show every mapping since Java SE 8. I think it is easier to look up. If this looks OK, I will file a CSR.

[AlanBateman]

Initially I thought listing LTSes in the expanded list, and put others collapsed. Then I thought LTS is an Oracle thing and not Java SE spec (although it's de-facto), so I am kind of hesitant to list them (CLDR might be OK as it is JDK imp). Thus ended up to list the recent 5 releases. Do you think it is OK to put Oracle's LTSes in the expanded supported Unicode versions?

I didn't mention LTS, my comment was more to have it include recent releases that are widely used as that. I see you've included a comment to aid future edits, I think it would be better to drop "LTS" from that note.

[AlanBateman]

Also, I changed the list in Character to show every mapping since Java SE 8. I think it is easier to look up. If this looks OK, I will file a CSR.

The resulting tables and expand to get "other" releases looks very nice now.

The paragraphs before the tables has "The following table lists", I think that will need to change to "tables" now.

There isn't any spec/normative change, it's just presentation so I don't think we strictly need a CSR for this.

[naotoj]

The paragraphs before the tables has "The following table lists", I think that will need to change to "tables" now.

Thanks. Updated the PR as suggested

[naotoj]

Thanks for the reviews!
/integrate

[openjdk]

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

• 46b93a0: 8248165: Missing whitespace in jdb message printed when setting value of invalid type
• d3158e7: 8379628: Refactor langtools/shellsupport/doc tests to use JUnit
• 680503c: 8378470: Add future Intel family number
• ... and 87 more: https://git.openjdk.org/jdk/compare/c52d7b7cbc89548c3e9cd68a29ff0cec04888b09...master

Your commit was automatically rebased without conflicts.

[openjdk]

@naotoj Pushed as commit 760f4b6.

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