Skip to main content

[JSR-354] Re: Next Steps

  • From: Werner Keil <werner.keil@...>
  • To: "Lincoln Baxter, III" <lincolnbaxter@...>
  • Cc: jcurrency_mail@..., rajmahendra@..., "Cech Previtali Susanne (KIVO)" <susanne.cechprevitali@...>, mark@..., "Baldry Scot (CS)" <scot.baldry@...>
  • Subject: [JSR-354] Re: Next Steps
  • Date: Fri, 31 May 2013 15:48:53 +0200

Lincoln,

Thanks for the follow-up. There is no JSR or SE Platform this JSR would automatically release into, at least not a "Platform" or "Umbrella" JSR. Java 8 is not final, though some "snapshots" just are announced, and it will take a year or more before business customers will even evaluate it. 

Regarding Java EE your remark is a good point, as Java EE 7 has been released or will be out any day from now (June 12 I believe) but here it seems a bit similar. By the time JSR 354 must go final under the requirements of JCP.next (no more than 24 months from now, but as in the previous messages, Anatole is hoping to get it out more along the lines of 12 months from now, plus/minus a few) Java EE 7 may be established, but products using Java EE 6 are still maturing (see http://fernandorubbo.blogspot.dk/2013/05/jboss-eap-610-is-out.html EAP 6.1 was released just 10 days ago) so if we look at Java EE, I can't say, if EE 7 was the best bet, but we could take the risk of using SE/EE 7 as a minimum requirement. 
One strong argument is, that Java 7 improved the java.util.Currency class, and even though java.util.Currency may not implement elements of JSR 354 until probably Java SE 9, any bridge, adapter or method-compatible part of the JSR 354 RI should make use of that if possible. 

So  reason tells us, Java 7 (and thus Java EE 7) seems like a good bet for a minimum platform, even at the cost of some EE products lagging behind a bit, or taking time before they can make full use of it.

Werner

On Fri, May 31, 2013 at 3:36 PM, Lincoln Baxter, III <lincolnbaxter@...> wrote:
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.  

~Lincoln


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 (http://www.jugchennai.in) 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:

https://java.net/projects/javamoney/forums/message-forum/topics/90419-Telco-Meeting-Preparation

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 (JCP.next) 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 java.net 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.

 

Regards,

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

 



Last but not least, an Independent, but compatible implementation of JSR 354 is progressing at Eclipse: http://www.eclipse.org/uomo/ 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 Eclipse.org

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+ gplus.to/wernerkeil

* 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
http://ocpsoft.org
"Simpler is better."



[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
 
 
Close
loading
Please Confirm
Close