Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 3 commits into from

Conversation

@naotoj
Copy link
Member

@naotoj naotoj commented Feb 12, 2021

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

Download

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Feb 12, 2021

👋 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 openjdk bot added the rfr label Feb 12, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Feb 12, 2021

@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
Copy link
Member Author

@naotoj naotoj commented Feb 12, 2021

/csr

@openjdk openjdk bot added the csr label Feb 12, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Feb 12, 2021

@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
Copy link

@mlbridge mlbridge bot commented Feb 12, 2021

Webrevs

bplb
bplb approved these changes Feb 12, 2021
Copy link
Member

@bplb bplb left a comment

Looks fine to me.

Copy link
Contributor

@RogerRiggs RogerRiggs left a comment

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

* <tr><td>Java SE 11</td>
* <td>Unicode 10.0</td></tr>
* <tr><td>Java SE 9</td>
* <td>Unicode 8.0</td></tr>
Copy link
Contributor

@AlanBateman AlanBateman Feb 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

@naotoj naotoj Feb 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@jddarcy jddarcy Feb 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

@naotoj naotoj Feb 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 openjdk bot removed the csr label Feb 17, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Feb 17, 2021

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

@openjdk openjdk bot added the ready label Feb 17, 2021
@naotoj
Copy link
Member Author

@naotoj naotoj commented Feb 17, 2021

/integrate

@openjdk openjdk bot closed this Feb 17, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Feb 17, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Feb 17, 2021

@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
Copy link
Member

@dholmes-ora dholmes-ora commented Feb 18, 2021

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
Copy link
Contributor

@RogerRiggs RogerRiggs commented Feb 18, 2021

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
Copy link
Member Author

@naotoj naotoj commented Feb 19, 2021

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.

@naotoj naotoj deleted the JDK-8261621 branch Feb 19, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Feb 22, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment