[12] RFR: 8215303: Allowing additional currency code points from later Unicode updates

[Chris Hegarty]

Thanks Naoto.

> On 4 Jan 2019, at 17:10, naoto.sato at oracle.com wrote:
> 
> Hi Chris,
> 
> Yes, it will affect the behavior of those methods. This has been discussed within the JLS folks, and their understanding was that the risk is minimal and OK to proceed. I was not involved in the discussion, but here are the reasons I can think of.

Ok. Should the CSR be updated to indicate this?

> - The Currency Symbols range is very limited (U+20A0-U+20CF)
> - The change is to allow the code point, not the way around, so existing identifiers are guaranteed to work.
> - Apart from this CSR, this kind of behavior change is common when a Unicode upgrade is done.

Sure, all good and valid reasons.

Will compilations with `--release N-1` wind back the set of allowable 
identifiers?  It possibly should, if so how does one do similar when/if
the set of currency characters is expanded in an update release?

-Chris.

> Naoto
> 
> On 1/4/19 6:13 AM, Chris Hegarty wrote:
>> On 1/3/19 10:26 PM, Naoto Sato wrote:
>>> Hello,
>>> 
>>> Please review the fix to the following issue (and its approved CSR):
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8215303
>>> https://bugs.openjdk.java.net/browse/JDK-8215305
>>> 
>>> The proposed changeset is located at:
>>> 
>>> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/
>> I think this is a positive change, but for clarity ( since I cannot find it
>> in the CSR ), will this change have an impact on the set of allowable
>> characters that can be used as identifiers, i.e. isJavaIdentifierStart,
>> isJavaIdentifierPart?
>> -Chris.