Skip to main content

[JSR-354] Re: Next Steps

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Next Steps
  • Date: Sun, 2 Jun 2013 23:30:31 +0200


Sorry to hear you won't be able to commit to the JSR any more. As soon as is finished (the license and IP part may still take a while, so not sure,  when it'll go final, but JSR 358 also just undergoes a Renewal Ballot like this one, so it won't take forever) there should be a new type of member for people like you, at the moment the existing Observer role should do for such cases. 

All who are interested and willing to help should however be able to contribute to the RI, restrictions only apply to the Spec and public API, but not RI or other projects especially javamoney-extras or similar

Glad we proactively keep people's status up to date here btw. anticipating what hopes to improve.


On Sun, Jun 2, 2013 at 10:36 PM, Sascha Freitag <dunschtig@...> wrote:
Hi all,

I'm fine with the fact, that inactive EG members will be removed. And one of the leaving persons will be me. I have to switch over to be an observer only because I have decided to take a new challenge in an other company. And as far as I know yet, this company has not signed the necessary stuff so that I can stay an EG member.

Cheers Sascha

On 31.05.2013 14:39, Tresch Anatole (KFSC 225) wrote:

Hi Werner/all


Ye, perhaps I have to to clarify a bit:

·         everybody is allowed to follow the mailing list as observer.

·         I also agree, that interested people outside of the ED can also participate/contribute for the reference implementation. Beside the organization alignment the git merge feature is an excellent tool for this on the technical side.

·         Inactive members may be removed as expert team member. IMO there must be a minimal contribution to participate as EG member and basically this was also agreed upon by each then filling out the form for becoming an EG member.


So basically with a minimal commitment, everybody that is able to commit somehow and in a reasonable way, is welcome. Though work on the specification itself and the API is clearly driven by the EG and the spec lead.




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: Friday, May 31, 2013 13:48
To: jcurrency_mail@...
Cc: rajmahendra@...; Cech Previtali Susanne (KIVO); mark@...; Baldry Scot (CS); Lincoln Baxter, III
Subject: [JSR-354] Re: Next Steps


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"


Sascha Freitag v/o Dunschtig

[JSR-354] Re: Next Steps

Sascha Freitag 06/02/2013

[JSR-354] Re: Next Steps

Werner Keil 06/02/2013
Please Confirm