8261621: Delegate Unicode history from JLS to j.l.Character

[naotoj]

Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.

---

Progress

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

Issue

• JDK-8261621: Delegate Unicode history from JLS to j.l.Character

Reviewers

• Brian Burkhalter (@bplb - Reviewer) ⚠️ Review applies to 5560a4cf96ae4816b4bf912bb8a40a64ea56e76d
• Joe Wang (@JoeWang-Java - Reviewer) ⚠️ Review applies to b026b5eb63a3ccddf3faacbc65f0e0b69d78ac79
• Roger Riggs (@RogerRiggs - Reviewer) ⚠️ Review applies to b94b41c
• Joe Darcy (@jddarcy - Reviewer)

Download

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

[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 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.

[naotoj]

/csr

[openjdk]

@naotoj has indicated that a compatibility and specification (CSR) request is needed for this pull request.
@naotoj please create a CSR request and add link to it in JDK-8261621. This pull request cannot be integrated until the CSR request is approved.

[mlbridge]

Webrevs

• 03: Full - Incremental (c90cd66)
• 02: Full (b94b41c)
• 01: Full - Incremental (b026b5eb63a3ccddf3faacbc65f0e0b69d78ac79)
• 00: Full (5560a4cf96ae4816b4bf912bb8a40a64ea56e76d)

[bplb]

Looks fine to me.

[RogerRiggs]

The table is informative and should not be construed as specification.
The wording "has supported" should be sufficient.

[AlanBateman]

Do we really need the history in the API docs? Will will update this table if there is a MR of the JSR for Java 8 that moves to a new Unicode release?

[naotoj]

This was requested by Alex, and I thought it sounded reasonable and informative. I think if an MR upgrades the supported Unicode version, it should be listed here.

[jddarcy]

Should some acknowledgement be made to the changes in Unicode support done by the Java SE 8 and Java SE 11 MRs with respect to extensions of the base Unicode version?

[naotoj]

I thought about that but decided not to include them here because the changes made in those MRs were not Unicode version upgrades (i.e., version stayed the same). Let me know if you think otherwise.

[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:

8261621: Delegate Unicode history from JLS to j.l.Character

Reviewed-by: bpb, joehw, rriggs, darcy

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

• d5a4d22: 8261843: incorrect info in docs/building.html
• bf75a3a: 8261851: update ReflectionCallerCacheTest.java test to use ForceGC from test library
• 05301f5: 8257497: Update keytool to create AKID from the SKID of the issuing certificate as specified by RFC 5280
• cb84539: 8261553: Efficient mask generation using BMI2 BZHI instruction
• a065879: 8261791: (sctp) handleSendFailed in SctpChannelImpl.c potential leaks
• 9ba2b71: 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal
• f639df4: 8261401: Add sanity check for UseSHM large pages similar to the one used with hugetlb large pages
• 2e18b52: 8261752: Multiple GC test are missing memory requirements
• c7885eb: 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails if ergonomics detect too small InitialHeapSize
• 05d5955: 8261522: [PPC64] AES intrinsics write beyond the destination array
• ... and 12 more: https://git.openjdk.java.net/jdk/compare/6b6f7940515c623b9e75b20ae536ce5e0ad66030...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.

[naotoj]

/integrate

[openjdk]

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

• d5a4d22: 8261843: incorrect info in docs/building.html
• bf75a3a: 8261851: update ReflectionCallerCacheTest.java test to use ForceGC from test library
• 05301f5: 8257497: Update keytool to create AKID from the SKID of the issuing certificate as specified by RFC 5280
• cb84539: 8261553: Efficient mask generation using BMI2 BZHI instruction
• a065879: 8261791: (sctp) handleSendFailed in SctpChannelImpl.c potential leaks
• 9ba2b71: 8261657: [PPC64] Cleanup StoreCM nodes after CMS removal
• f639df4: 8261401: Add sanity check for UseSHM large pages similar to the one used with hugetlb large pages
• 2e18b52: 8261752: Multiple GC test are missing memory requirements
• c7885eb: 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails if ergonomics detect too small InitialHeapSize
• 05d5955: 8261522: [PPC64] AES intrinsics write beyond the destination array
• ... and 12 more: https://git.openjdk.java.net/jdk/compare/6b6f7940515c623b9e75b20ae536ce5e0ad66030...master

Your commit was automatically rebased without conflicts.

Pushed as commit ea5bf45.

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

[dholmes-ora]

The table is informative and should not be construed as specification.
The wording "has supported" should be sufficient.

If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification?

[RogerRiggs]

The current version of Unicode is specified in a normative statement just before the table.
"Character information is based on the Unicode Standard, version 13.0."

The table is not a specification of past revisions.

[naotoj]

RIght. And each Java SE release's spec has the same sentence with the version replaced. In fact, vendors cannot incorporate arbitrary Unicode versions as it would involve API changes. If they wanted to do so, an MR should have to be released.

[mlbridge]

Mailing list message from David Holmes on i18n-dev:

On 20/02/2021 12:00 am, Naoto Sato wrote:

On Thu, 18 Feb 2021 14:49:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

The table is informative and should not be construed as specification.
The wording "has supported" should be sufficient.

If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification?

The current version of Unicode is specified in a normative statement just before the table.
"Character information is based on the Unicode Standard, version 13.0."

The table is not a specification of past revisions.

RIght. And each Java SE release's spec has the same sentence with the version replaced. In fact, vendors cannot incorporate arbitrary Unicode versions as it would involve API changes. If they wanted to do so, an MR should have to be released.

Roger and Naoto, thanks for clarifying. I took Roger's original comment
out of context.

David