1. javamoney

RI artifacts found their way into Spec/API


    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 0.4-EDR1
    • Fix Version/s: 0.4-EDR1
    • Component/s: None
    • Labels:


      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 as it exists today.

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

      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 (or, should the standalone approach this undermines be abandoned?) package space. Notable exceptions would be Collection API or JNDI with both Context and InitialContext in

      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.


        No work has yet been logged on this issue.


          • Assignee:
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Due: