Thanks for backing the point made by a couple of others both in and outside the EG. Given the ongoing but shorter than both EE 8 or SE 8/9 development the JSR has still to undergo, Java 7 seems most reasonable.
If there's really big demand under SE6/7 somebody could write a fork/backport similar to what Stephen did with 310.
In UOMo 0.6 Milestone I also had to branch off the pre-Kepler (ICU 50+) generation, mostly affecting the Early Preview of UOMo Business with ICU Currency being alligned with Java 7 from 50, but compatible with Java 6 only till ICU 4.4.
Raj and JUG Chennai mentioned porting the JSR to Android, well, there both the ICU and "JDK alike" version of the VM won't even be at the level of Java 7 or sometimes 6 either;-)
better late then neve. In my view it's crucial to be able to use the Money API as fast as possible also in EE context. And I think this was also the reason for choosing the mixed approach i.e. not only targeting a JDK integrated one. So I would like to see the things based on JDK 7, also to tease the application a little to migrate ;-).
On 19.05.2013 21:00, Werner Keil wrote:
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, seehttp://google-web-toolkit.googlecode.com/svn/javadoc/2.5/index.html?com/google/gwt/i18n/client/package-summary.html
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)
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 ;-)
2013/5/18 Werner Keil <werner.keil@...>
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,
WernerAm 18.05.2013 17:43 schrieb "Anatole Tresch" <atsticks@...>:
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.
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather
Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDRSkype 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"
-- Sascha Freitag v/o Dunschtig
[JSR-354] Re: JSR 354 Outlook