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.s...@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.
