Published using Google Docs
Scope JSR 354
Updated automatically every 5 minutes

Variant

Platform

Profile

Standalone

Mixed

Scope

  • Money (final value type)
  • Enhancements to existing java.util.Currency
  • Interfaces MonetaryAmount, CurrencyUnit for Interoperability
  • mechanism to perform pluggable calculations, such as MonetaryAdjuster
  • formatting (extensions to NumberFormat)
  • Integration existing EE features (e.g. CDI) is not relevant.
  • the scope of the JSR would be targeted explicitly at what is appropriate for JavaSE:
  • e-commerce and financial accounting, rather than high-frequency trading or high-end finance
  • 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

  • Goal would be adding functionality to so called Profiles of the Java Platform. Either the “Web”, “Full” or other future profiles of Java EE, as well as profiles like ME Embedded (JSR 361) or others like CDC.
  • Implementations of MonetaryAmount and CurrencyUnit determined by implementations.
  • No enhancements to existing java.util.Currency
  • Interfaces MonetaryAmount, CurrencyUnit for Interoperability
  • complex formatting requirements possible (but without extensions to NumberFormat)
  • Integration/lifecycle management using EE features like CDI or their Component/Service model for other profiles is key objective.
  • the scope of the JSR would be targeted explicitly at what is appropriate for JavaEE:
  • competing implementations
  • CDI integration
  • separate RI
    for each platform
    (i.E. EE 8 and CLDC 8 would each require their own RI)
  • separate TCK
    for each platform
    (i.E. EE 8 and CLDC 8 would each require their own TCK)
  • separate specification
  • code can rely on language and library features of Java 7 or even 6 if appropriate
  • Implementations of MonetaryAmount and CurrencyUnit determined by implementations, but RI can provide Money for multiple target SE environments.
  • No enhancements to existing java.util.Currency
  • Interfaces MonetaryAmount, CurrencyUnit for Interoperability
  • Implementations of MonetaryAmount and CurrencyUnit determined by implementations.
  • mechanism to perform pluggable calculations, such as MonetaryAdjuster
  • Main lifecycle management by Monetary singleton.
  • EE integration (CDI) as extension (e.g. using producers).
  • separate RI
  • separate TCK
  • separate specification
  • integration with EE can be easily modelled as extended functionality
  • Basically similar scope as Standalone plus Platform JSR.
  • Creation of a standalone JSR now, and possible follow-up JSR (part of this, could be new version or simply OpenJDK project) for Java SE functions/features. Aiming at Java 9 Release Train.

Main Goal

the JSR goal would be to add code to OpenJDK in JDK 1.9 or equivalent parts of the platform

the JSR goal would be to define an API/SPI for usage in a EE context

the JSR goal would be to define an API/SPI for usage in any suitable Profile.

the first JSR goal would be standalone due to the late schedule of JDK 1.9, then additional JSR/release/JEP is targeting Java 9

Package Name

java.money or javax.money

javax.money

javax.money

javax.money

Advantages

  • small and clear scope
  • better integration of existing java.util.Currency
  • comes with JDK
  • different requirements can be covered by different implementations.
  • all features discussed can be defined as part of this JSR
  • RI can benefit from EE or ME/Embedded features
  • different requirements can be covered by different implementations.
  • all features discussed can be defined as part of this JSR
  • JSR can still be partially integrated into SE later, e.g. core APIs
  • JSR can support EE integration as extension.
  • JSR can easily be used in SE and EE environments.
  • JSR can also easily used in ME environments.
  • JSR can be used/extended as it is official.
  • integration into JDK as javax package may still be possible, if Oracle wants to, but not mainly targeted.
  • better integration of existing java.util.Currency
  • different requirements can be covered by different implementations.
  • all features discussed can be defined as part of this JSR
  • JSR can support EE integration as extension.
  • JSR can easily be used in SE and EE environments.
  • JSR can also easily used in ME environments.
  • JSR can be used/extended as it is official.
  • integration into JDK as javax package is still possible and JSR design should be appropriately reflect this.

Disadvantages

  • none of the JSR code would be usable before JDK 1.9 is released or equivalent parts of the platform
  • additional design constraints due to platform integration
  • Many important use cases in the financial area can not be covered.
  • Bugfixes only as part of JDK patches!

  • increased complexity in this JSR
  • more detailed spec/RI/TCK required, though some likely shared with Profile team
  • no enhancements to SE java.util.Currency, but can be adapted/ introduced  in certain Profiles if agreed by Oracle
  • increased complexity in this JSR
  • detailed spec/RI/TCK required.
  • no enhancements to SE java.util.Currency (but can be adapted or used by certain Profiles if agreed by Oracle)
  • JDK changes related to JSR would not be usable before JDK 1.9 is released or equivalent parts of the platform
  • nevertheless the JSR can be used also prior to JDK merge, since javax packages can be deployed independently.
  • separation into SE/non-SE part is the most complex variant.
  • complex interdependencies between SE and non-SE part (Spec, RI, TCK etc).
  • SE/EE release schedules may have severe implications on this JSR, or the follower JSR