Skip to main content

[JSR-354] Re: Public Review Feedback

  • From: "Tresch, Anatole " <anatole.tresch@...>
  • To: "'jcurrency_mail@...'" <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Public Review Feedback
  • Date: Mon, 27 Jan 2014 19:01:46 +0000
  • Accept-language: de-CH, en-US

Hi Werner

I will take that up on the next phone call with the Javaland guys...

Cheers
Anatole



Sent with Good (www.good.com)


-----Original Message-----
From: Werner Keil [werner.keil@...<mailto:werner.keil@...>]
Sent: Monday, January 27, 2014 06:36 PM
To: jcurrency_mail@...
Subject: [JSR-354] Re: Public Review Feedback

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[cid:347@goomoji.gmail])

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.

Cheers,
Werner


On Mon, Jan 27, 2014 at 6:14 PM, Anatole Tresch 
<atsticks@...<mailto: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 ;-)

WDYT?

Cheers,
Anatole




2014-01-27 tom.huesler@...<mailto:tom.huesler@...> 
<tom.huesler@...<mailto:tom.huesler@...>>

Anatole

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.

Regards,
Tom

On 27.01.2014, at 13:47, Anatole Tresch <atsticks@...<mailto: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 plans.
- 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!

Regards,
Anatole



2014-01-27 Werner Keil <werner.keil@...<mailto: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 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<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 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@...<mailto: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/
Google: atsticks
Mobile  +41-76 344 62 79<tel:%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: atsticks
Mobile  +41-76 344 62 79<tel:%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: atsticks
Mobile  +41-76 344 62 79<tel:%2B41-76%20344%2062%2079>

GIF image



[JSR-354] Re: Public Review Feedback

Tresch, Anatole 01/27/2014
 
 
Close
loading
Please Confirm
Close