Bug ID: JDK-8215305 Allowing additional currency code points from later Unicode updates

Type: CSR
Component: core-libs
Sub-Component: java.lang

Priority: P2
Status: Closed
Resolution: Withdrawn
Fix Versions: 12

Submitted: 2018-12-12
Updated: 2019-01-15
Resolved: 2019-01-14

Summary
-------

Relax the java.lang.Character specification to allow code point additions for newly defined currency symbols.

Problem
-------

Currency symbols are assigned in Currency Symbols Unicode Block (U+20A0..U+20CF), but the actual defined currency symbols in that block vary over Unicode releases. For example, the BitCoin sign (U+20BF) is only available in Unicode 10 and after. This means that it is usable only in JDK12 and after. 

Solution
--------

Relax the expected character property values for the code points in currency symbols block so that later code point additions will not affect the JavaSE conformance.
For the code points currently undefined in the range of U+20A0..U+20CF, the return values from these methods may change in the future. Specifically,

    Character.isDefined(char/int) returns 'true'
    Character.getType(char/int) returns CURRENCY_SYMBOL
    Character.getName(char/int) returns the name of the currency
    Character.getDirectionality(char/int) returns the value other than DIRECTIONALITY_UNDEFINED
    Character.UnicodeScript.of(char/int) returns COMMON 



Specification
-------------

Add the following paragraph in java.lang.Character class description, just before the "Unicode Character Representations" section:

     * <p>
     * @implSpec The code points in {@link Character.UnicodeBlock#CURRENCY_SYMBOLS
     * Currency Symbols} {@code UnicodeBlock} that are unassigned as of the
     * <a href="#UnicodeVer">Unicode version noted above</a>,
     * may be defined for currency symbols assigned by the Unicode
     * Consortium from later updates. The definition of additionally assigned 
     * code points is implementation specific.

Modify the section that refers to the Unicode Version to an HTML anchor element, with additional explanation:

     * Character information is based on <a id="UnicodeVer">the Unicode Standard,
     * version 11.0.0</a> Additional currency symbols (and Japanese Era Square character) defined subsequent to that Unicode version may be present.

We have decided not to allow future blanket additions of currency code points.
14-01-2019
As per the discussion on core-libs-dev, it may be useful to have the CSR or maybe the release note maybe it clear that if new currency symbols are added by an implementation then source code using those symbols in identifiers may not compile with implementations of the same Java SE release that do not support the symbols.
06-01-2019
[~naoto], my general comment earlier was that the spec update should provide some hint about what the future changes might be present, as the updated version does. Moving to Approved.
22-12-2018
This CSR is intended for allowing the future additions of currently unassigned code points for the backports without modifying the spec, so at the time of releasing the (mainline) JDK, it is exactly the same as the Unicode version noted above. Thus it is not possible to describe what are the additions to the Unicode version N as in your @implNote example. I will change the current @implNote to @implSpec, and modify the Unicode version sentence with "Additional currency symbols (and Japanese era)...".
18-12-2018
I think the intention of this change should be made more explicit and more spec-ful. For example, something like: "Character information is based on <a id="UnicodeVer">the Unicode Standard, version 11.0.0. Additional currency symbols (and Japanese era and ...) defined subsequent to that Unicode version may be present, see XYZ for details." The text given in the @implNote above has to be some sort of spec text (i.e. plan text or @implSpec) since it is mandating certain behavior be implementation defined. A reasonable pairing would be, for instance, [Text saying currency symbols not defined by Unicode N may still have defined behavior] @implNote This JDK supports the additional currencies not defined in Unicode N: * DukeCoin * ... or reference to some external document, release notes? with that information. I'm marking the request as pended until this small details can be sorted out.
18-12-2018