Skip to main content
This revision made January 05, 2013 23:38, by Anatole


JSR 354 - Design Principles


The following design principles were identified to be useful for this JSR:

Design Principles for the Specification

  • use Value types (simple immutable types, depending on even simpler immutable types or primitives)
  • Encapsulate implementation details, especially in monetary amounts encapsulate the number representation.
  • Strictly separate value types from formatting and parsing.
  • Strictly separate value types from conversion logic.
  • Use long formatted UTC timestamps.
  • Use plain Java interfaces were possible.
  • Were useful do reuse existing JDK artifacts, instead of reinventing new ones.
  • Clearly separate the application programming interface (API) from the service provider interface (SPI). The API must never depend on the SPI, where the other way round may be possible.
  • Define static accessors for the API/SPI artifacts.
  • Separate different concerns into different APIs/SPIs.
  • Allow multiple SPI implementations to be registered at a time by providing according separation rules, where possible (and useful). As an example a CurrencyProvider defines the namepsace it is responsible for, whereas multiple namepsaces can be define by multiple providers registered.
  • Where an operation can only fail due to extraordinary reason, avoid using checked exceptions. In case, were a failure must be expected, use checked exceptions.
  • Method naming and style in alignment with java.util.Currency, where applicable BigDecimal, unless otherwise recommended by (Oracle) Platform Architects
    • same method name prefixes - getInstance() for factories, other operations modeled after BigDecimalto the extent it makes sense. See JavaFX or other APIs.
    • overall API "feel" shold mirror BigDecimal, unless otherwise recommended by (Oracle) Platform Architects
  • Works acceptably with other JVM languages (Groovy, Scala, Clojure...) most do with java.util.Currency, or BigDecimal, thus integration will be similar.
    • Possibly have to align with OpenJDK and other parts like JavaFX

Design Principles for the Reference Implementation

  • Use java.util.ServiceLoader for loading of SPI implementations.
  • If possible/useful model classes that implement API interfaces as non final, so they can freely extended by clients.
  • Use net.java.javamoney as root package.

Open Points

  • There is some debate about whether to use factories, why lock it down?
    • No separate factories for the value types
      • specifically, users should be able to write Money.getInstance(30, GBP) or similar. Factories may exist separate to this, but should not be the first design option.
Difference compared to previous revision
=
JSR 354 - Design Principles


The following design principles were identified to be useful for this JSR: === Design Principles for the Specification * use '''Value types''' (simple immutable types, depending on even simpler immutable types or primitives) * '''Encapsulate implementation details''', especially in monetary amounts encapsulate the number representation. * Strictly '''separate value types from formatting and parsing'''. * Strictly '''separate value types from conversion''' logic. * Use long formatted '''UTC timestamps'''. * Use '''plain Java interfaces''' were possible. * Were useful do '''reuse existing JDK artifacts''', instead of reinventing new ones. * Clearly '''separate''' the application programming interface ('''API''')''' from''' the service provider interface ('''SPI'''). The API must never depend on the SPI, where the other way round may be possible. * '''Define static accessors''' for the API/SPI artifacts. * '''Separate different concerns''' into different APIs/SPIs. * '''Allow multiple SPI implementations''' to be registered at a time by providing according separation rules, where possible (and useful). As an example a CurrencyProvider defines the namepsace it is responsible for, whereas multiple namepsaces can be define by multiple providers registered. * Where an operation can only fail due to extraordinary reason, avoid using checked '''exceptions'''. In case, were a failure must be expected, use checked exceptions. * '''Method naming and style'''=
JSR 354 - Design Principles


The following design principles were identified to be useful for this JSR: * use '''Value types''' (simple immutable types, depending on even simpler immutable types or primitives) * Method naming and style in '''alignment with java.util.Currency''', where applicable BigDecimal, unless otherwise recommended by (Oracle) Platform Architects ... * Works acceptably with other JVM languages (Groovy, Scala, Clojure...) most do with java.util.Currency, or BigDecimal, thus integration will be similar. ** Possibly have to align with OpenJDK and other parts like JavaFX == Op in '''alignment with java.util.Currency''', where applicable BigDecimal, unless otherwise recommended by (Oracle) Platform Architects ** same method name prefixes - getInstance() for factories, other operations modeled after BigDecimalto the extent it makes sense. See JavaFX or other APIs. ** overall API "feel" shold mirror BigDecimal, unless otherwise recommended by (Oracle) Platform Architects * Works acceptably with other JVM languages (Groovy, Scala, Clojure...) most do with java.util.Currency, or BigDecimal, thus integration will be similar. ... * Works acceptably with other JVM languages (Groovy, Scala, Clojure...) most do with java.util.Currency, or BigDecimal, thus integration will be similar. ** Possibly have to align with OpenJDK and other parts like JavaFX ===Desigen Pon Printciples D foro w the waReferentce Implemen to tation * Use <inclucode >java.uthil.ServiceLoader for e followloading of SPI implementations. *ing as a Ifpossible/useful '''model classes''' that desigimplementn p API interfaces as '''non final''', so they can freely extended by clients. * Use net.java.javamoney as root rinciplpackage?. ===Open Points *There is some debate about whether to use factories, why lock it down? ** No separate factories for the value types *** specifically, users should be able to write Money.getInstance(30, GBP) or similar. Factories may exist separate to this, but should not be the first design option.
 
 
Close
loading
Please Confirm
Close