Skip to main content

[JSR-354] Re: Locale Extensions

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Locale Extensions
  • Date: Thu, 7 Feb 2013 13:46:56 +0100

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 or
Note this JEP even supports a new Turkish Currency sign!
Those are the only 3 i18n ones for SE 8.


On 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,



Anatole Tresch


Information Technology | Java Core Framework & Support, KSXK 23

Zollstrasse 20/36 | 8070 Zürich | Switzerland

Phone +41 44 334 03 89

anatole.tresch@... |


From: Werner Keil [mailto:werner.keil@...]
Sent: Thursday, February 07, 2013 13:24
To: jcurrency_mail@...
Subject: [JSR-354] Re: Locale Extensions


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.


Speak soon,




On Thu, Feb 7, 2013 at 9:02 AM, Anatole Tresch <atsticks@...> wrote:

Dear All


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.






Anatole Tresch

Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon


Switzerland, Europe Zurich, GMT+1

Twitter:  @atsticks

Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79


[JSR-354] Locale Extensions

Anatole Tresch 02/07/2013

[JSR-354] Re: Locale Extensions

Werner Keil 02/07/2013

[JSR-354] Re: Locale Extensions

Tresch Anatole (KFSC 225) 02/07/2013

[JSR-354] Re: Locale Extensions

Werner Keil 02/07/2013
Please Confirm