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

[naoto.sato at oracle.com]

Hi Chris,

Yes. I just updated the CSR, adding the description in the compatibility 
risk:

https://bugs.openjdk.java.net/browse/JDK-8215305

Naoto

On 1/4/19 9:18 AM, Chris Hegarty wrote:
> 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.
>