8261621: Delegate Unicode history from JLS to j.l.Character #2538
Conversation
|
|
|
/csr |
|
@naotoj has indicated that a compatibility and specification (CSR) request is needed for this pull request. |
Webrevs
|
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> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
@naotoj This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be: 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
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.
|
|
/integrate |
|
@naotoj Since your change was applied there have been 22 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit ea5bf45. |
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. 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. |
|
Mailing list message from David Holmes on i18n-dev: On 20/02/2021 12:00 am, Naoto Sato wrote:
Roger and Naoto, thanks for clarifying. I took Roger's original comment David |
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
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/2538/head:pull/2538$ git checkout pull/2538The text was updated successfully, but these errors were encountered: