Skip to main content

[JSR-354] Re: Next Steps

  • From: Anatole Tresch <atsticks@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Next Steps
  • Date: Fri, 31 May 2013 20:30:38 +0200

Hi Lincoln/all

exactly, if we had more time, we possibly could discuss releasing into Java 8. But since it is planned to speed up to release this year, we certainly have to stick on 7.
Java 8 comes with some really interesting new features, e.g. the new date/time API and the "functional language extensions". Therefore I think that we have to consider them as far as possible, so we can support them in the future with no harm, e.g. with a JSR's maintenance release. Also due to the JCP process we had to abandon the platform focus, since this JSR will be closed before release of JDK 9. But also Oracle agrees on the fact that we can move this JSR (or parts of it) into the Java platform at a later stage. Until then the standalone scope allows to gain further experience. So summarizing JDK 8 being late also has its advantages. 


2013/5/31 Lincoln Baxter, III <lincolnbaxter@...>
Hello All,

I think my inclusion here is based on a comment I made on twitter about not using JDK7 because most users are still on JDK6 ? If that is the case, then yes, we still target JDK6, but I'm a little confused as to what this discussion is actually about. If the debate is whether to target JDK7 or JDK8 for compatibility  then I suspect the answer will be based on which version of the SE or EE platform this JSR actually releases into.  


On Fri, May 31, 2013 at 7:47 AM, Werner Keil <werner.keil@...> wrote:
Dear Anatole/all,

Thanks a lot for the message. One or two casual remarks inline.

On Fri, May 31, 2013 at 12:29 PM, Tresch Anatole (KFSC 225) <anatole.tresch@...> wrote:

Dear All


The EDR feedback period will soon be over. There was not much feedback, but generally we have good feedback (!) for our work here, also from colleagues that I have the chance to talk with them directly. So I think we can proceed for the next step, which is Public Review, followed by the Public Review Ballot. RI and TCK still are not part of this step, but it makes sense to continue working on them, since this helps also to keep the scope of our JSR defined and TCK testability also is directly related with the specification’s quality.


Also with the presentations at - more or less - every Java One conference (India, Russia, Shanghai, hopefully also San Francisco) the topic has significantly gained awareness also in the whole community (thanks to all EG colleagues that were actively presenting the JSR at the conferences). Also hereby I would like to encourage all of the EG members to help this JSR gain publicity even more, by speaking at tech conferences at your locations, and/or contact your local JUGs for inviting you to present this JSR. The adopt programs (adoptJSR/adoptOpenJDK) are a very important part to be in contact with the people that actually are using and at the end also supporting the Java platform . Also JUG Chennai ( already started adapting our JSR and also plans to migrate it for small devices. On the expert area on the JCP page you will find several presentations and also according templates for your CFP, so there is not much work needed (beside knowing this JSR well, which I assume is the case, when actively contributing to it ;-) ). If have any questions or need more support, just get in contact with me…


I hope, the EG Members at JavaOne (EC duties will bring me there the week before, and it looks like I'll stay there in any case, regardless what talks I get involved in) and ideally you as Spec Lead get a chance in San Francisco. While Victor starting the JSR was already awarded with a JCP Award last year, I see no reason not to nominate you for doing a great job of pulling it out of the risky situation, the whole JSR or both this year again, so fingers crossed if you were granted a trip to JavaOne, there could be more than one occasion to attend
We have an EG Member at PayPal in Sao Paulo, so while I might go to Brazil if invited to talk at JavaOne S America in December, we would have somebody there, too, if he and/or his company are interested and able to do so.

In my last mail I was thinking if we should base on Java 8 instead of 7, but with the planning for having this JSR final until end of year, we can not go for Java 8. Nevertheless we can do all what is possible to be prepared for Java 8 and then create a maintenance JSR to fully support JDK8 features. Therefore I also think, that we should define a corresponding/dedicated interest area so the API overall is well prepared.


Based on input not only from GR8Conf and SpringSource/vmware, but others like Lincoln (I CC him here on behalf of EC Member Red Hat) also confirmed, solutions they got support java.util.Date or similar (JDK 7 and before) types rather than some added to Java 8 beside those.
Let's not go into discussion here about actual data type, maybe a "Solomonian" verdict here could be generics in some places, allowing both earlier JDKs and where ready later ones to work. Especially for passed arguments a <D> fromDate instead of either Long, Instant, Date or something else could be best. And for the whole aspect of validity, legal tender, etc. we had a brief discussion with Mark from Google in Zurich, along the lines of what some of us discussed for the Legal Tender earlier, so a solution here could be factoring this into a different place and making the CurrencyUnit or MonetaryAmount leaner and smaller, too.

I prepared a rough agenda for a next telco/hangout within next one or two weeks. Feel free to update/add topics as needed:

I would prefer doing a hangout, but if needed, I can also do both, and see who will be joining on each meeting. I will send out the doodle until EOD MET


Again I would like to denote one separate person for each area of interest, who actively helps driving the progress of that according area. Also I would like a commitment of each EG member on which areas he can contribute. I also consider the next TelCo/hangouts as mandatory. The ones who will not be able to join, I would like to contact me directly, so we can get in contact in another way. Finally those that did not have done any contributions during the last months (joining the email discussion, also sporadically, is considered at least a small contribution) and will not get in contact with me, are assume they are not willing or further being able to be part of this EG, so I will be asking Oracle to remove them from the EG member list.


I'd say this is along the lines of several EC Members' arguments and discussions in the JSR 358 ( working groups about different levels of involvement for Individual or other members. 
Each person affected by this shall not be removed from this mailing list, in JCP terms they'd become an "Observer" instead of a "Full EG Member", still allowing not only to read the mailing list (at the moment we only have one, and that has been approved by PMO) but to reply. Only write/push access to the main "Spec" repositories of the JSR and probably JIRA will not be possible for those who are not EG Members. 

I leave that to Anatole or discussing it in the next calls, but from a JCP/PMO point of view and how some other JSRs, including those lead by Oracle handle it, contributing to the RI and TCK projects under Apache License should be open to non EG-members, too, but you'd have to request access. Neither nor Github have self-registration for committers, but if you're willing to contribute to any of these projects, feel free to ask the Spec Lead or project admins, and they'll help you with this.

Some of the EDR feedback was already translated into two topics on our discussion forum. The other aspects best fit into our JIRA systems, mostly of them are concerning extensions and considerations to the specification document. I will add the tickets also within the next days, along with the original emails.


Ooph! Quite a big message! Nevertheless I am looking forward for the next months and I think, that we will be capable of successfully deliver a substantial extension to the Java ecosystem within the next months.





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


Last but not least, an Independent, but compatible implementation of JSR 354 is progressing at Eclipse: UOMo 0.6 is just undergoing a Release Review by Eclipse Foundation this week (similar to EDR or Public Draft, but a bit faster and voted on by groups like PMC or an Architecture Council
UOMo Business, the part aiming to implement this JSR is not a key part of this release yet, but as soon as JSR 354 becomes available to common code repositories like MavenCentral, the follow-up releases will make use of it and implement the JSR on top of ICU4J. Beside Eclipse important platforms for this are all environments using ICU4J, including GAE, GWT or Harmony and of course Android, where ICU is built-in, and thus the biggest chunk UOMo is based on won't have to be downloaded any more

At an "Observer" level to start with, contributing to mailing lists, forum or Bugzilla tickets, before you may become a committer if the majority of active committers vote in favor (slightly different from JCP where only the Spec Lead does that, but generally comparable) so those of you who may be interested to use JSR 354 in any of the mentioned environments (any compatible OSGi container including many popular Java EE servers also qualify btw, they may need to download ICU4J, but otherwise it's similar) feel free to check out UOMo Business at

Kind Regards,

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

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

Skype werner.keil | Google+

* Eclipse DemoCamps Kepler 2013: June 19-28 2013, Germany, Denmark, Austria. Werner Keil, UOMo Lead, Mærsk DevOps Build Manager will present "Triple-E’class DevOps with Hudson, Maven, Kokki, Multiconf & PyDev", "M4M 2 the Rescue of M2M"

Lincoln Baxter, III
"Simpler is better."

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] Next Steps

Tresch Anatole (KFSC 225) 05/31/2013

[JSR-354] Re: Next Steps

Jeff Prestes 05/31/2013

[JSR-354] Re: Next Steps

Werner Keil 05/31/2013

[JSR-354] Re: Next Steps

Tresch Anatole (KFSC 225) 05/31/2013

[JSR-354] Re: Next Steps

Lincoln Baxter, III 05/31/2013

[JSR-354] Re: Next Steps

Werner Keil 05/31/2013

[JSR-354] Re: Next Steps

Anatole Tresch 05/31/2013
Please Confirm