From: Werner Keil <werner.keil_at_gmail.com>
Date: Fri, 8 Feb 2013 09:15:59 +0100

Markus,

Thanks a lot for the quick response.

While one may see such types as "language enhancements" and
java.util.Currency is clearly a natural candidate for RI where applicable,
the examples of javax.xml (JAXP and other JSRs) or CDI (version 2 will aim
for SE option, too) show that some important enhancements and foundations
of EE were later integrated with SE or (as discussed for JSON) even future
Embedded profiles.

Brian Goetz said, even proposed as platform catering JSR something like 354
won't have to wait for SE 9 to be created in OpenJDK or equivalent projects
(e.g. the JavaCard Umbrella and most of ME have embraced kenai.com over
java.net and still do;-) However, should it go the platform/project way,
for EE doors would be locked till EE9. While a standalone version of such
JSR could be used in theory all the way back into EE6 applications, and I
guess you know best here, there aren't even too many EE6 certified
containers actively used by Production quality projects yet;-)

Werner
Am 08.02.2013 07:04 schrieb "Markus Eisele" <myfear_at_web.de>:

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