TCK and RI will be developed as standalone modules. RI is intended for distribution as part of Java SE version 8 but can run standalone
I believe, the ICU4J Region is not for much more than such standard areas and codes either btw.We should try to experiment e.g. with "variant" and see, if it can be tweaked under SE 7/8. Guess SE 8 Locale is also almost finalized, e.g. JEPs like this http://openjdk.java.net/jeps/127 or http://openjdk.java.net/jeps/128Note this JEP even supports a new Turkish Currency sign! http://openjdk.java.net/jeps/133Those are the only 3 i18n ones for SE 8.WernerOn Thu, Feb 7, 2013 at 1:37 PM, Tresch Anatole (KFSC 225) <anatole.tresch@...> wrote:
· Yes, but region is defined to be ISO 3166 alpha-2 country code or UN M.49 numeric-3 area code. So there is not much capability for modeling other classifications than ISO regions. Also when we then think of historic regions, this may render to be not sufficient enough. For mapping of alternate country schemes you are also completely lost.
· Introduction of Currency.Builder makes sense for me.
· Similar to ExchangeRate.Builder (in that context also the naming of the according interface has to be discussed, since it clashes with that name).
· In format/parsing this already has been designed accordingly, but not yet with the same naming convention…
Regards and here you soon,
CREDIT SUISSE AG
Information Technology | Java Core Framework & Support, KSXK 23
Zollstrasse 20/36 | 8070 Zürich | Switzerland
Phone +41 44 334 03 89
Thanks, note, the Locale.Builder also supports setRegion(), so I think we might have to reconsider some separate stuff there and where it behaves strange or unexpected try to help Java 9 to address some of that within the scope of Unicode or other standards.
The Builder pattern, used also in JavaFX is something worth keeping an eye on. Whether a final value type like java.util.Currency gets this as a static Currency.Builder, like in Locale, or a more consequent approach similar to JavaFX (with its interface Builder<T>) is preferable, let us discuss and see.
javafx.util.Builder could have potential for more than just JavaFX, but that either in the core or ext JSR certainly was a possible idea, too.
On Thu, Feb 7, 2013 at 9:02 AM, Anatole Tresch <atsticks@...> wrote:
I was playing around with Locale extensions on JDK 7/8. There was some strange behavior with toString() and extension input validation.
Summarizing I was able to create Locale instances that were not valid as defined in the specs (with duplicate singletons or tags).
More details are described in my blog entry here:
For our use cases according formatting/parsing the mechanism implemented by the JDK looks for me far too restrictive, to be able to replace, what we have defined as of now int the format package.
[JSR-354] Scope of the JSR, RI and TCK