javamoney
  1. javamoney
  2. JAVAMONEY-38

RI artifacts found their way into Spec/API

    Details

    • 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:
      None

      Description

      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.

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            atsticks
            Reporter:
            keilw
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved: