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
- ATMsBeside 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.WernerOn Thu, Feb 7, 2013 at 6:55 PM, Stephen Colebourne <scolebourne@...> 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
- 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
- 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.
[JSR-354] Re: Strawman scope - JavaSE only