Proposal: Extend Unicode support for GB 18030-2022

[Iris Clark]

The China Electronics Standardization Institute [0] has recently published the
mandatory standard GB 18030-2022 [1] which requires additional code points
available in Unicode 11.  Java SE 8 and 11 support older Unicode Standards [2].
The issues are:

  - (JSR 337) The Java SE 8 Specification supports Unicode 6.2.  The Unicode
    conformance section in class java.lang.Character should be updated to
    allow code points in the range of U+9FCD to U+9FEF (35 code points) to
    support GB 18030-2022, Implementation Level 1. [3]

  - (JSR 384) The Java SE 11 Specification supports Unicode 10.0.  The Unicode
    conformance section in class java.lang.Character should be updated to
    allow code points in the range of U+9FEB to U+9FEF (5 code points) to
    support GB 18030-2022, Implementation Level 1. [4]

Additionally, we would like to take this opportunity to add the system
property "java.specification.maintenance.release" to Java SE 11, thus aligning
it with Java SE 8 and releases Java SE 19 and beyond.  The issue is:

  - (JSR 384) The Java SE 11 Specification does not have a programmatic means
    to identify whether a JDK is implementing an original or maintenance
    release of the Java SE specification.  The system property
    "java.specification.maintenance.release" was added in Java SE 19 and
    subsequently backported to Java SE 8 via MR 4.  This system property
    should be backported to Java SE 11. [5]

To resolve these issues for future JDK updates, I'll shortly propose
Maintenance Releases of the Java SE 8 [6] and the Java SE 11 [7] Platform JSRs
in the JCP to apply these changes.  This will require updates to the
Specification, the Reference Implementation (RI), and the TCK, which my Oracle
colleagues and I will provide.  I expect the Maintenance Release process to
complete by May 2023, in time for these changes to be merged into the July
security releases of JDK 8 and JDK 11.

Following the practice introduced in the JSR 337 February 2020 Maintenance
Release, we want to reduce risk by basing the open-source RI on the RI for the
previous Maintenance Release, rather than the most recent OpenJDK Updates
release.  We propose to label the RI builds as "8u43" and "11.0.0.1" in order
to convey that they are outside the contemporary train of update releases, and
(like prior RI builds such as 8u42) they are neither meant for production use
nor are they updated with security fixes.

We intend to contribute the changes required by these MRs to the next
appropriate OpenJDK 8 and 11 Updates releases (most likely 8u382 and 11.0.20
respectively).

Comments?

Iris

[0]: http://www.cesi.cn/page/index.html
[1]: https://ken-lunde.medium.com/the-gb-18030-2022-standard-3d0ebaeb4132
[2]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/Character.html#conformance
[3]: https://bugs.openjdk.org/browse/JDK-8301557 [SE 8]
[4]: https://bugs.openjdk.org/browse/JDK-8301558 [SE 11]
[5]: https://bugs.openjdk.org/browse/JDK-8285764 [SE 11 sys prop]
[6]: https://jcp.org/en/jsr/detail?id=337
[7]: https://jcp.org/en/jsr/detail?id=384