<i18n dev>  RFR: 8215303: Allowing additional currency code points from later Unicode updates
chris.hegarty at oracle.com
Mon Jan 7 10:11:38 UTC 2019
> On 5 Jan 2019, at 17:03, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 04/01/2019 17:18, Chris Hegarty wrote:
>> 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?
> I don't think `javac --release` takes the Unicode version into account.
That is a bug.
> I agree with your comment that the CSR could be be expanded to at least make it clear that if support for a currency symbol is added in some future update of JDK N then source code using it in identifiers will compile with the JDK update that supports the symbol, not by the GA or previous updates of JDK N.
The question is whether, or not, it is reasonable to allow ( part of )
the set of Java identifiers, in the language, to be an implementation
detail? If so, then certain code compiled and run on BuzzCorps Java
implementation may not compile or run on WollyInc's Java implementation.
( Both are compliant Java SE implementations )
I accept that the set of implementation specific currency characters
may noy be all that large, but this does seem like a significant
change, and I want to ensure that the implications are fully understood.
More information about the i18n-dev