[JSR-354] Re: Public Review Feedback
- From: Werner Keil <werner.keil@...>
- To: "jcurrency_mail@..." <jcurrency_mail@...>
- Subject: [JSR-354] Re: Public Review Feedback
- Date: Mon, 27 Jan 2014 18:30:58 +0100
Sounds like a good idea.
If JavaLand as I heard rumors gets its share of "Java 8 Launch" events,
then either some hackathons or similar hands-on gatherings might be a good
idea to give the API a try in its state then (since all Java 8 components
and platforms are waved through until then, it may not be so easy to get
PMO time for a PR2 before that anyway[?])
Unless the Java 8 spec is wrong, what's been designed to be Lambda-capable
will work with Lambda, and it sounds interesting to test some scenarios
out, especially around conversion or other "functional" aspects of the JSR.
Should JavaLand organizers grant me access as a "Hackathon helper" or
similar even without a main talk, I'd love to help, I guess I can spend up
to a day, but it would have to be coordinated with the JSR-362 F2F.
On Mon, Jan 27, 2014 at 6:14 PM, Anatole Tresch <atsticks@...> wrote:
> Hi all,
> or as an alternative, since we already have quite much feedback and
> basically there is no major change in the API regardless, if we use JDK 7
> or 8 (we are already prepared for JDK 8), we might simply add the
> conversion aspects (as already ongoing) and publish another full public
> review. If we can do some sessions with LJC also in the meantime, this
> would be optimal, Some of them might even use our API/RI with JDK 8 out of
> the box ;-)
> 2014-01-27 tom.huesler@... <tom.huesler@...>
>> If need be, let's do ballot but I personally am hesitant to target for
>> Java 8.
>> Most larger financial companies I know are still on Java 6, prob. just
>> starting with 7. Targeting the JSR to 8 will (in my opinion) make it
>> unused for a long time. Also vendors might like to see it different, a
>> larger company does not upgrade it's stack just for the sake of actuality.
>> Of course we could do the back-port but so far I do not really see an
>> advantage for this.
>> On 27.01.2014, at 13:47, Anatole Tresch <atsticks@...> wrote:
>> Hi all
>> I personally tend also to stay on 7 for the API, but LJC is not any
>> member it's one of the most important members in the Java community. So my
>> proposal is to write down all advantages and disadvantages and create a
>> ballot/query inviting all interested parties around the world to help us to
>> take that decision finally. So the argumentation above gives already a lot
>> of pros to stay on AR7. Everybody that has a different opinion (also only
>> following this mailing list) is kindly invited to write down pros and cons
>> and share them with us. With that I will create a short online query around
>> end of week and we will see rather fast, what will be the outcome here.
>> The query itself will have several questions, so we can also see, what is
>> the people's interest and background, summarizing:
>> - which version of Java are you using currently?
>> - do you use Java 7? Not yet, planned to migate within next 6 months, 3
>> years, not yet decided.
>> - when do you plan to use Java 8? Within 1 year, 2 years, longer or no
>> - which is your preferred Java version for the API?
>> - which is your preferred Java version for the RI/TCK?
>> - If we base on JDK 8, should we also use 310 types, or go for an
>> independent but flexible API instead.
>> - In what area are your working: developer, consultant, architect, ..
>> - what is the main focus of your company: software industry, financial
>> services, other (+what else)
>> - how many employees has your company, or your main customers (if working
>> as a developer/consultant): -10, -100, -1000, bigger?
>> So this should be done in 5 minutes and give us better input on this
>> decision. When we have a clear statement, we should take a decision and
>> stick to it!
>> 2014-01-27 Werner Keil <werner.keil@...>
>>> Dear Anatole/all,
>>> Thanks for the summary.
>>> Looking at the results and comments by all EC Members I would not at all
>>> say there is a "strong tendency" that we should base the JSR on JDK 8. A
>>> single member suggested it. While the vast majority of EC Members not only
>>> voted "Yes" (some with comments about missing functionality, mostly stuff
>>> that got removed during the JavaOne gathering) but also see Java 7
>>> A "pollution" of the API/Spec itself with let's say the
>>> @FunctionalInterface annotation would bind the API to Java SE 8, making it
>>> useless to both CLDC 8 and Java 7. About supporting Lambdas, there seems
>>> be a common misunderstanding, that only this annotation makes the API
>>> Lambda-friendly, but that's not the case, see
>>> Every interface in javax.money like MonetaryOperator and others meet the
>>> criteria of a functional interface, thus if you use Java 8 you can use
>>> in Lambdas, but the codebase is compatible with at least Java 7 or CLDC 8
>>> (Java ME 8), too. The API under javax.money should be portable and refrain
>>> from direct references to JDK8, its types or annotations. Most importantly
>>> Java EE has just come up with 7, it'll be another 2-3 years minimum till
>>> 8 may get finalized, and the average lifecycle of commercial products
>>> much longer. Everybody who was at the JUG Summit before the EC F2F last
>>> week heard, that most of Oracle's own "Cloud" or "Social" offerings are
>>> still based on "J2EE 5" (that's when the term J2EE was still
>>> common<329.gif>) thus haven't even be updated to Java EE 6, not to mention
>>> 7. A mission critical system I work on here in Germany won't upgrade to
>>> Java 7 because of mandatory safety vetting for those systems, even though
>>> Java 7 could improve the performance in some cases, and in production this
>>> "Very Long Term Support" case means Java 6 is going to be the basis of it
>>> for the next 20 to 30 years<322.gif>
>>> Regarding RI and TCK the proposal of our JSR actually states this:
>>> 2.16 Please describe how the RI and TCK will de delivered, i.e. as part
>>> of a profile or platform edition, or stand-alone, or both. Include version
>>> information for the profile or platform in your answer.
>>> TCK and RI will be developed as standalone modules. RI is intended for
>>> distribution as part of *Java SE version 8 *but can run standalone
>>> I am not sure, how the "part of SE 8" slipped into the proposal, most
>>> likely Victor assumed, it might be offered inclusion if finished before a
>>> feature freeze of SE 8, but unless the PMO objects, I see no reason why we
>>> could not base RI and TCK on SE 8 and also use functionality it provides
>>> the implementation, but not the API/Spec (the part under "javax.money")
>>> On Mon, Jan 27, 2014 at 8:34 AM, Anatole Tresch <atsticks@...>wrote:
>>>> Dear All
>>>> public review has been passed with 24 yes and 1 no vote. Basically the
>>>> spec is it stands for now is on the right track. Nevertheless there is
>>>> important feedback, mainly to be summarized as follows:
>>>> - there is a strong tendency that we should base our JSR on JDK 8,
>>>> instead of 7. This would have several benefits, such as the usage of
>>>> Lambdas for predicates and operators, queries. The disadvantage would
>>>> that we have to create a JDK7 backport (which I expect should not be
>>>> difficult). Also the usage of 310 date/time types will be arguable,
>>>> but I
>>>> think this topic has to be discussed saeparately. There are
>>>> to define attributes, but leave the effective implementation type
>>>> which would allow us to use 310 types in SE, but alternates in other
>>>> platforms, such as ME.
>>>> - also conversion should be included in the JSR. The disadvantage
>>>> here, also mentioned by me at the EC meeting last week, would be that
>>>> a JSR
>>>> may not be self-contained, or at least, may perform outdated
>>>> since for conversion you need an according (external) data feed. Also
>>>> conversion is not a simple thing, different companies do it
>>>> differently and
>>>> it is important that we model it as flexible as possible. Therefore I
>>>> started to move the existing conversion functionalities to the API
>>>> but hereby simplifying/extending things to be able to pass a
>>>> (instead of ExchangeRateType). Such a context allows to pass a
>>>> provider (similar to the former ExchangeRateType), but would also
>>>> support additional parameters (type safe), such as a target
>>>> timestamp, a
>>>> source amount or whatever may be required in the current use case.
>>>> Hereby the final design of ConversionContext is still work in
>>>> progress and I will write another mail, when I think, the current
>>>> state is
>>>> ready for discussion/decision.
>>>> - Additionally I hope (see also my last cc'ed mail), we are able to
>>>> do some hand-on session with the colleagues from LJC, similar at it
>>>> done with JSR 310. This will for sure boost our API further and
>>>> we will then have a version, where all stakeholders can agree on it
>>>> was the one that voted with no in the ballot).
>>>> *Anatole Tresch*
>>>> Java Lead Engineer, JSR Spec Lead
>>>> Glärnischweg 10
>>>> CH - 8620 Wetzikon
>>>> *Switzerland, Europe Zurich, GMT+1*
>>>> *Twitter: @atsticks*
>>>> *Blogs: **http://javaremarkables.blogspot.ch/
>>>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>> *Anatole Tresch*
>> Java Lead Engineer, JSR Spec Lead
>> Glärnischweg 10
>> CH - 8620 Wetzikon
>> *Switzerland, Europe Zurich, GMT+1*
>> *Twitter: @atsticks*
>> *Blogs: **http://javaremarkables.blogspot.ch/
>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
> *Anatole Tresch*
> Java Lead Engineer, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
Description: GIF image