Skip to main content

[JSR-354] Re: JSR 354 Outlook

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Cc: patrick@...
  • Subject: [JSR-354] Re: JSR 354 Outlook
  • Date: Sun, 19 May 2013 21:00:05 +0200

Well following the conversation we had with Mark from Google in Zurich and your thoughts, I looked at how GAE, GWT or others use JodaTime or ICU4J. See this StackOverflow post:

And the most interesting package of SWT including a very CurrencyUnit like interface named CurrencyData, see

We'll have to speak to Mark, but in future versions of GWT CurrencyUnit could potentially be used, the two are very similar.
Where it comes to exposing internal libraries both JodaTime, ICU4J or others GWT is pretty clear on the JDK only path, and until Java 8 is final I doubt either GWT or JSR 354 are supposed to use any of these in a public API. 

Internally an RI seems pretty free to use any library, JodaTime, even the ThreeTen Backport, as long as a JSR public API does not expose any of that, just see how GWT and similar frameworks do. Generally no JSR must rely on another non final  standard, else Java EE wouldn't traditionally follow SE by at least 2-3 years

One remarkable thing in the java.util package is the new Builder. Its setInstant http://download.java.net/jdk8/docs/api/java/util/Calendar.Builder.html#setInstant(java.util.Date)
does not refer to java.time.Instant directly, but builds the instant using either long primitive or java.util.Date.

The only direct reference to the Instant class is a toInstant() in the abstract Calendar base class. 

Not sure, if Instant was useful to JSR 354, but aside from the general Temporal (allowing to use Instant, LocalDateTime, etc. instead of baking one implementation into a method) and in some cases maybe Duration (especially where something is valid for a certain time) it seems like the few direct references possible. 

If we even require the isValidFrom() or isValidTo() methods in the public API is also a good question. Ben briefly raised it in Zurich. 
Some methods could be moved from the most integral base interface (CurrencyUnit) into other specialized ones, look at the one for getDisplayName(). Thus factoring such aspects into specialized interfaces could help making this more flexible. It may be left from 1.0 or refer to a type that's already available in Java 6/7. Concrete final value types like the MoneyCurrency or (THAT is a crucial point where Oracle's input and vision is very important) java.util.Currency may use Java 8/9 types in an MR or the future version of the JSR for Java 9 (if it evolves faster than OpenJDK does in the meantime)

Cheers,
Werner 

On Sun, May 19, 2013 at 8:16 PM, Anatole Tresch <atsticks@...> wrote:
I think, we will have to decide finally also together with Oracle. For me personally all variants would work (releasing earlier based on 7 and to a MR, or releasing finally later, but based on Java 8. I would not change anything to the existing  codebase before this is clear ;-)

Cheers,
Anatole


2013/5/18 Werner Keil <werner.keil@...>

Anatole/all,

Just read the November deadline, but I'm afraid, a non-final JSR and JDK is an absolute no-go, so either Final release would have to slip, or 310 integration planned for a 1.x release or MR of 1.0
I would prefer that to a backport, but let's see what others say.

Greetings from Eurovision Park,
Werner

Am 18.05.2013 17:43 schrieb "Anatole Tresch" <atsticks@...>:
Dear Colleagues

as you all know, JSR 354 is currently in EDR until end of May. Nevertheless I want to give some feedback, about I would like to proceed with this JSR. This mail can be also seen as the outcome of the presentation and discussions during the EC F2F meeting here in Zurich of this week and the conferences held by several EG members.
  • Since Java 9 will be so late, that our JSR would be closed before by the JCP process, the mixed scope is not possible. Additionally, since also Oracle sees this JSR as a very important extension to the JDK, it gives as more time for gaining experience with it before adding it to SE 9, by going for a standalone scope.
  • Several discussions with different people during the last weeks also let me change my mind, according backward compliancy with JDK 6/7. I think, we should go for JDK8, use the new 310 types and also benefit from functional interfaces, lambdas and especially also streams. Our JSR will for sure profit from this features.
  • Java 6/7 support still can be achieved by providing a backport to this JSR within some external Open Source project.
  • Additionally I initiated at the EC meeting that we should have a more representative expert group, so we really are defining the best JSR possible. As a result Google, Goldman Sachs and possibly others should also join our EG, and give feedback. Oracle, if not joining directly, will at least provide advice and technical assistance.
  • Also Credit Suisse wants more actively support this JSR. As a result it is planned having this JSR complete until November this year.
  • As we do here very fundamental stuff, which may also be very interesting for other eco-systems/languages, we should talk also with them,.., so our work may be also useful for other organizations beyond the Java eco-system.
I think these are the most important points. With the quite challenging roadmap, I also want to streamline our expert group. This means:
  • Everybody in the EG must check, if he is able and willing to contribute to our JSR within the next months actively. On beginning of June I will organize some Hangout, where I would like to define the different streams on which further work has to be done. I expect that each stream leader acts proactively and also does a corresponding planning and ensures reasonable progress.
  • Those EG members that were silent since last year or already know that they are not able to at least actively follow and participate on the discussions, can write me a mail personally. I will then remove them from the EG member list. Of course, they are still invited to observe our JSR's progress.
Of course, as always, if anybody has feedback or I missed something, let me know.

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



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



--

Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather

Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDR

Skype werner.keil | Google+ gplus.to/wernerkeil

* GR8Conf Hackergarten: May 22 2013, Copenhagen, Denmark. Werner Keil, JCP EC Member, JSR 354 EG Member will present "Groovy/Grails - Best way for Money using JSR 354"


[JSR-354] JSR 354 Outlook

Anatole Tresch 05/18/2013

[JSR-354] Re: JSR 354 Outlook

Werner Keil 05/18/2013

[JSR-354] Re: JSR 354 Outlook

Anatole Tresch 05/19/2013

[JSR-354] Re: JSR 354 Outlook

Werner Keil 05/19/2013

[JSR-354] Re: JSR 354 Outlook

Sascha Freitag 05/31/2013

[JSR-354] Re: JSR 354 Outlook

Werner Keil 05/19/2013
 
 
Close
loading
Please Confirm
Close