From: Markus Eisele <myfear_at_web.de>
Date: Fri, 8 Feb 2013 07:03:57 +0100

I don't see things like 354 separated from SE which is the platform base
for EE. Let's try not to bundle language enhancements separately to all
platforms.
It might be a different thing talking about the new SE Profiles where you
probably will have to fight for every MB.

By today we are not even embracing all the powerful new SE 7 features (e.g.
invoke dynamics) in EE, so even if I like to see a solution around Money
and Currency in Java someday, I personally don't see a reason to push it
separately to EE.

Follow-ups and questions off list please (might even be German ;))
- M

On 7 February 2013 21:29, Werner Keil <werner.keil_at_gmail.com> wrote:

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