[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 14:31:20 +0100
Thanks for the quick reply.
Programs like "Adopt-a-JSR" by LJC and SouJava[?] deserve recognition of
course, but don't mistake "playing around" with new features of Java 8 or 9
in hackathons or JUG meetings with real life projects in big companies. Or
vendors of products depending on Java. Like many of those (including 2
other JUGs) who voted in favor of the approach so far.
Who would be asked this survey? A representative number of people was asked
also, if the JSR should be included only with Java 9 in a "platform" (or
umbrella) distribution, and AFAIR a significant number voted against that.
Pushing it into a semi-platform JSR that is useless prior to Java 8 or 9
would be a slap in the face of all these who voted in favor of the
standalone approach. And that includes as important members of the JCP as
let's say Ed Burns (JSF Spec Lead[?])
As of now there is practically no usage of Date/Time values other than the
newly added "convert" package in the main API. Abstracting it via
ConversionContext properties means, you may add a 310 style attribute if
you use the API under Java 8. That looks good. As there are just as many
solutions and companies with other frameworks from Date4J to JodaTime.
The rest of the API already got Lambda-style functional interfaces, there
is almost no place where directly extending a JDK 8 pre-defined type would
safe something except let's say
java.util.function.UnaryOperator<MonetaryAmount> instead of MonetaryOperator
On Mon, Jan 27, 2014 at 1:47 PM, 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 to
>> 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 them
>> 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 EE
>> 8 may get finalized, and the average lifecycle of commercial products takes
>> 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[?])
>> 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[?]
>> 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 in
>> 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 open,
>>> 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,
>>> 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 was
>>> 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>*
Description: GIF image
Description: GIF image
Description: GIF image