Date: Thu, 7 Feb 2013 21:29:06 +0100
Dear Experts,
Sorry to bother you with this question in the middle of the EE 7 release
train being put on rails...
It does however affect future versions of Java EE, and the question, if a
JSR like 354, Money and Currency API for the Java Platform would be
available to EE 7 (at least as optional add-on) 8 or even just 9, should it
only become an integral part of Java SE 9...
Any thoughts on this?
The failed inclusion of JSR 107, also largely developed on GitHub btw.
could be seen as a Worst Case Scenario, but with some of the dedicated EG
Members like myself, Anatole and other CS colleagues, we'd actually expect
to be in time for CLDC 8, another Profile in the Java Platform it may cater
to, but if a* platform/profile* only delivery was decided for 354 unlike
e.g. 107 or most of what went into javax.xml (173, then JAXP, which is now
used by SE and EE alike) all developed standalone first and then used
accordingly, the EE community would sadly have to wait until Java EE 9
following SE 9 as usual.
WDYT?
If some of you have a strong opinion on that, please let me know, it may
but doesn't have to be on the whole mailing list. And optionally CC
Anatole, the Spec Lead of JSR 354, too: "Anatole Tresch" <atsticks_at_gmail.com
>
Thanks,
Werner
---------- Forwarded message ----------
From: Werner Keil <werner.keil_at_gmail.com>
Date: Thu, Feb 7, 2013 at 9:07 PM
Subject: Re: [JSR-354] Strawman scope - JavaSE only
To: jcurrency_mail_at_javamoney.java.net
Not to mention the time, it takes from a version of Java EE to be Final
till it gets applied to Products like Application Servers[?]
So far, not even Oracle Fusion Middleware has fully embraced Java EE 6 yet.
JBoss finalized its EAP 6 Product (based on EE6, that's why they also call
it 6) a few months ago, but not just my current client won't start using it
in the first "Green Field" projects until 6-12 months after that.
So imagine, when EE 9 with an SE 9 Money type and JSR included would hit
the market...? You'll watch the 2022 Football World Cup in Qatar first!!![?]
Given it isn't so irrelevant to the EE community, I guess I'll ask a quick
question to fellow EG members on its mailing list.
Also to raise awareness. Given, e.g. a standalone JSR was preferred there,
they're more than welcome to join this EG, at least some and help with
things like RI and TCK[?]
Werner
On Thu, Feb 7, 2013 at 8:53 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> Btw. I just looked at SE 7 and while there are 56 packages in the java.*
> namespace, it has 117 (more than twice as many) in the javax.* namespace.
> Many of them JSRs like 173, with then Spec Lead BEA (now also part of
> Oracle[?]) having gone Final with a standalone RI and TCK, but were later
> integrated as part of the JDK.
>
> Beside a vote and doodle from people who are interested and willing to
> express their preference, it is also up to CS as Spec Lead, whether they
> feel like releasing such TI and TCK prior to SE 9 or any profile like CLDC
> 8, whichever might come sooner.
>
> The main benefit for CS or other Financial Institutions (not so much End
> users of financial services, they use mostly Embedded devices unless they
> do Online Banking or their own personal finance with a tool like
> MoneyDance) would be, that Java EE, possibly as far back as 6 or 7, but
> certainly EE 8 could also use such standalone JSR.
>
> If introduced with SE 9 only, the EE world (leaving Embedded profiles
> aside) would have to wait for Java EE 9, god knows, when that's even going
> to really come out?[?]
> Wikipedia gives a nice idea when SE came out:
> http://en.wikipedia.org/wiki/Java_version_history
>
> So taking SE 6, it was released December 11, 2006.
> The EE equivalent http://en.wikipedia.org/wiki/Java_EE_version_historytells us, Java EE 6 was released December 10, 2009, practically the same
> day(!) but 3 years later.
> With EE 7, compared to the SE 7 release in Summer 2011, it looks like
> Oracle got back to an average of 2 years between an SE and EE release, so
> realistically, EE 9 could be expected around *2017*.
>
> If the SE 9 only option of this JSR was selected, then there's no way,
> Java EE could use it before that, unless some weird "backport" along the
> lines of what "org.threeten" now tries to accomplish. The official JSR
> would not be available before SE 9.
>
> While Embedded devices and customers could of course make use of it ahead
> of time, they'd only have to "spin it off" OpenJDK like CLDC 8 is going to
> to in the near future.
>
> Werner
>
>
> On Thu, Feb 7, 2013 at 8:23 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
>
>> That's a good summary of points, and part although not all of the
>> "platform/profile" option every JSR proposal offers.
>>
>> In fact, java.util.Currency was part of every JSR from 216 to 219, too
>> (various CDC profiles, those are more SE than ME or in between if you want
>> [?])
>> The first new profile happens to be the one defined by JSR 360 / 361, but
>> given this is equivalent to OpenJDK, parts if not all of it are intended to
>> be developed there (or at kenai.com) an integration can and will happen
>> sooner.
>>
>> Aside from the financial industry or accounting apps, the majority of use
>> cases where money is involved are things like
>>
>> - POS, Card Readers, either traditional or new forms like Square[?]
>> - Mobile Payment
>> - Toll Bridges, Road Pricing or similar access fees
>> - Pay TV, Set-Top Boxes, etc.
>> - Self-Service Vending Machines
>> - ATMs
>>
>> Beside a massive private Cloud of clustered WebLogic, JBoss, Apache and
>> other servers, looking at all the container, vessel and vehicle tracking
>> systems, Maersk has in place around the world, which type of Java Runtime
>> or OS (also Symbian or Windows CE of course) do you think dominates?[?] Not
>> just in this company.
>>
>> So the first time the API gets finalized is whenever the first plaform or
>> profile Oracle puts out uses it. That's driven by their demand, not what we
>> think is right depending and every new conference like JFokus, JavaOne,
>> DevoXX, etc. were quite clear about the importance of M2M and Embedded,
>> even if the average Desktop user and developer may not always notice it.
>>
>> Beside different timing and maybe size (e.g. there are likely less value
>> classes or supporting APIs like formatting,etc., if they are most except
>> the core Money and Currency type would e optional and only used in some
>> Profiles, e.g. Formatting where significant UI exists) all other conditions
>> are as Stephen mentioned for SE 9.
>>
>> Werner
>>
>> On Thu, Feb 7, 2013 at 6:55 PM, Stephen Colebourne <scolebourne_at_joda.org>wrote:
>>
>>> This is a strawman for an JavaSE only JSR.
>>>
>>> - the JSR goal would be to add code to OpenJDK in JDK 1.9
>>> - none of the JSR code would be usable before JDK 1.9 is released
>>> - the scope of the JSR would be targetted explicitly at what is
>>> appropriate for JavaSE
>>> - that scope is likely to be primarily about e-commerce and financial
>>> accounting, rather than high-frequency trading or high-end finance
>>> - package name either java.money or javax.money (see below)
>>> - example scope
>>> -- final value type class - Money
>>> -- enhancements to existing Currency class
>>> -- interface CurrenyUnit
>>> -- interface MonetaryAmount
>>> -- mechanism to perform pluggable calculations, such as MonetaryAdjuster
>>> -- formatting
>>> - no separate TCK, as integrated into OpenJDK/JDK .9
>>> - no separate specification, just Javadoc on code proposed to OpenJDK
>>> - code can rely on language and library features of JDK 1.8
>>>
>>> This outline is achievable and small in scope (much smaller than
>>> JSR-310).
>>>
>>> This strawman is strict wrt OpenJDK inclusion being the primary goal.
>>> Full integration into JDK 1.9 and OpenJDK must be achieved before
>>> considering java or javax package name. If the group, having completed
>>> the primary task of code ready for JDK 1.9, wished to continue to
>>> write a spec usable on JDK 1.7 or1.8, then it could. The steps would
>>> be:
>>> - request the javax.money package
>>> - write a standalone TCK
>>> - write a standalone specification
>>> - define other items/features that exist beyond the base spec
>>>
>>> It is vitally important not to lock down any specification that is
>>> intended to be part of JDK 1.9 until it is integrated into OpenJDK and
>>> Oracle are happy with it.
>>>
>>> Stephen
>>>
>>
-- Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDR Skype werner.keil | Google+ gplus.to/wernerkeil * Social Media Week: February 18 2013, Hamburg, Germany. Werner Keil, JCP Executive Committee Member, Agorava Co-Founder will present "Enterprise Social using Open Source Frameworks like Agorava" * Social Media Week: February 22 2013, Copenhagen, Denmark. Werner Keil, JCP EC Member, JSR 354 EG Member, Agorava Co-Founder will present "Enterprise Social using Open Source Frameworks like Agorava", "Social Currencies and Crowdfunding"
