Skip to main content

[JSR-354] Scope of the JSR, RI and TCK

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Scope of the JSR, RI and TCK
  • Date: Thu, 7 Feb 2013 16:46:52 +0100

Dear Anatole/all,

Thanks for setting up the call. It was good to discuss these initial items.

For the doodle, please let's refer to 

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

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


As Mike from Fujitsu highlighted before the Renewal Ballot, the Java SE version should be revised, as 8 has been frozen bz now. 2.16 is quite clear, that you can aim for BOTH, and that should also be an option for the doodle (whether SE 9 was to integrate "javax.money" like it does with Dozens of other "javax.*" packages by now, or refactor it like "java.time" from 310, that is not our concern for now.
Profile (as CLCD 8) and Platform (as SE 8 or 9) are more or less the same, the only difference is, that with both an ME/Embedded profile and SE Platform there would be the need for 2 separate sets or RI and TCK as Patrick emphasized. Oracle will pick which profile/platform they find is most appropriate, all we have to decide, is whether we want to go the platform/profile option, standalone (meaning towards EE or similar based on the lowest Java version we feel is appropriate, 7 or even 6)  or both?

Upon the decision, as the SE 8 phrase is outdated anyway, it's a good opportunity to correct that.

Cheers,
Werner


On Thu, Feb 7, 2013 at 1:46 PM, Werner Keil <werner.keil@...> wrote:
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/128
Note this JEP even supports a new Turkish Currency sign! http://openjdk.java.net/jeps/133
Those are the only 3 i18n ones for SE 8.

Werner

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

 

Anatole Tresch

CREDIT SUISSE AG

Information Technology | Java Core Framework & Support, KSXK 23

Zollstrasse 20/36 | 8070 Zürich | Switzerland

Phone +41 44 334 03 89

anatole.tresch@... | www.credit-suisse.com

 

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,

Werner

 

 

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.

 

Regards,

Anatole

 

--

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] Scope of the JSR, RI and TCK

Werner Keil 02/07/2013

[JSR-354] Re: Scope of the JSR, RI and TCK

Werner Keil 02/07/2013

[JSR-354] Re: Scope of the JSR, RI and TCK

Werner Keil 02/07/2013

[JSR-354] Re: Scope of the JSR, RI and TCK

Werner Keil 02/07/2013
 
 
Close
loading
Please Confirm
Close