[JAVAMONEY-38] RI artifacts found their way into Spec/API Created: 06/Apr/13  Updated: 08/Aug/13  Due: 07/Apr/13  Resolved: 14/Apr/13

Status: Closed
Project: javamoney
Component/s: None
Affects Version/s: 0.4-EDR1
Fix Version/s: 0.4-EDR1

Type: Bug Priority: Critical
Reporter: keilw Assignee: atsticks
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes


This may have been well-intended or fueled by "inspiration" from JSRs like 310 where concrete implementations like Duration are hiding underlying base types such as TemporalAmount, but fact is, concrete final classes Money, MoneyCurrency and MoneyRounding do not belong to the Spec/API in a package like javax.money as it exists today.

If a ThreeTenesque design was intended, a massive restructuring would have to be considered.
Either moving all "javax.money" elements into a sub-package like "javax.money.api" (JSR 352 followed a similar approach, but AFAIK left the root package intentionally empty) or "javax.money.core" could pave the way for putting concrete implementing classes into javax.money.

However, if those "default implementations" are based on BigDecimal like the current Money class, that means, the Spec/API would contain elements of the RI in its root package, and those opposing the use of BigDecimal had to live with this type while not using it.
Worse, given BD does not exist in CLDC the API or Core Module would not be compatible without sub-setting.

The question is quite serious, and requires distinct answers by at least Oracle JDK architects, if they are happy and willing to ignore/deprecate java.util.Currency in favor of a default implementation in the javax.money (or java.money, should the standalone approach this undermines be abandoned?) package space. Notable exceptions would be Collection API or JNDI with both Context and InitialContext in javax.name

IntegralMoney, currently part of the RI should then maybe moved to "ext", while the entire ext question stil needs to be clarified, e.g. de-scoping some of those from the Spec. Having one class of the RI in a completely diffent package/artifact while having all others directly in the main root package of the Spec itself makes it very inconsistent.

Also, if this "default implementation" approach is sanctioned by Oracle/OpenJDK, this means, the jdk-stub will have to die, as it no longer makes any sense that way.

Comment by atsticks [ 07/Apr/13 ]

Isolated core part targeting SE platform on same level as standalone API/TI/TCK.
Will discuss solution with EG in a separate mail with other latest topics and changes/proposals. As for now projcet structure is as follows:

SE scope:

  • money-platform: contains the standalone API/RI
    • money-platform-api: contains the api targeting JDK SE 9
    • money-platform-ri: contains the implementation artifacts targeting JDK SE 9

Standalone scope

  • money-api: contains the standalone API part
    • convert: currency conversion
    • format: foramtting and parsing
    • provider: accessors
    • ext: extensions
  • money-impl: contains the standalone implementation artifacts
    • ri: contains the reference implementation, runnable on SE 7 or later
    • cdi: contains alternate loader implementation using standalone CDI (weld)
    • java-ee: contains alternate loader targeting EE 6 CDI container integration
  • money-tck: contains the technical compatibility kit (TCK)
Generated at Sun Feb 14 04:33:48 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.