Skip to main content

[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 12:10:25 +0100

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
appropriate.
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
http://download.java.net/jdk8/docs/api/java/lang/FunctionalInterface.html

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")

Regards,
Werner


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 some
> 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 be,
>    that we have to create a JDK7 backport (which I expect should not be that
>    difficult). Also the usage of 310 date/time types will be arguable, but I
>    think this topic has to be discussed saeparately. There are possibilities
>    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 conversion,
>    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 part,
>    but hereby simplifying/extending things to be able to pass a 
> ConversionContext
>    (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 was done
>    with JSR 310. This will for sure boost our API further and hopefully we
>    will then have a version, where all stakeholders can agree on it (LJC was
>    the one that voted with no in the ballot).
>
>
> Regards,
> Anatole
>
> --
> *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/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile  +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
>

Attachment: 329.gif
Description: GIF image

Attachment: 322.gif
Description: GIF image



[JSR-354] Public Review Feedback

Anatole Tresch 01/27/2014

[JSR-354] Re: Public Review Feedback

Werner Keil 01/27/2014

[JSR-354] Re: Public Review Feedback

Anatole Tresch 01/27/2014

[JSR-354] Re: Public Review Feedback

Werner Keil 01/27/2014

[JSR-354] Re: Public Review Feedback

tom.huesler@... 01/27/2014

[JSR-354] Re: Public Review Feedback

Anatole Tresch 01/27/2014

[JSR-354] Re: Public Review Feedback

Werner Keil 01/27/2014
 
 
Close
loading
Please Confirm
Close