[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED
- From: Stephen Colebourne <scolebourne@...>
- To: jcurrency_mail@...
- Subject: [JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED
- Date: Mon, 28 Jan 2013 22:46:04 +0000
I think that the money API is an order of magnitude simpler than JSR-310.
Dates have two interlinked concepts
- periods or durations, which are quantities measured in terms of
terms of a unit, such as "6 seconds" or "7 days"
- dates/times, which are points on some form of time-line, queryable
by fields, such as hour-of-day or month-of-year
Money only has the first concept - quantities measured in terms of a
unit, such as "65 dollars".
Furthermore, JSR-310 will be part of JDK 1.8. Many of the design
principles will be able to be copied pretty much directly. To do
otherwise would be a mistake in terms of missing the lessons learned
and for JDK users who would then have a different style of quantity
API to learn.
IMO, the JDK needs one or possibly two representations of a monetary
quantity, one of which should be called Money, and should be an
immutable value type. Exactly as the
Temporal/TemporalAccessor/TemporalAmount interfaces enable other
non-JDK implementations of datetime, interfaces should then be added
to allow non-JDK implementations of money. (In many ways, the design
starts from replacing "Temporal" by "Monetary" and seeing what
310 has a TemporalUnit interface, so I would think a similarly
designed CurrencyUint interface would be appropriate as well. If at
all possible, I would suggest retaining the existing Currency class as
the only one in the JDK, but it would need to be able to support
pluggable currency data.
Finally, a mechanism for querying and adjusting is needed. This could
be modelled on TemporalQuery/TemporalAdjuster if it can be made to
The provision of additional money/currency classes outside the JDK
core is a valid design goal, as in JSR-310. But the core in the JDK
must be effective and broad enough to cater for the 80% of users that
just want to store the money value and perform basic calculations.
On 28 January 2013 20:42, Anatole Tresch <atsticks@...> wrote:
> Dear all!
> For me it is crucial that we really know what for a SE targeting JSR is
> really required by Oracle. Whereas in an EE context decoupling is absolutely
> crucial, so interfaces are really the better way accessing "things", we have
> to discuss these things in a SE context obviously. Personally if it is
> really required as described by Stephen (which I guess is the case, thanks
> Stephen), I am asking me, also having a in mind the complexity of use cases
> seen, if we are not better to target both EE and SE, or even EE without SE.
> Let me explain a bit my considerations:
> Variant 1: Separation into a SE and EE part:
> In the SE part:
> we define the interfaces for a simple CurrencyUnit, and adapt the
> java.util.Currency class accordingly. We keep the interface simple and
> stupid (no historization, no attributes or extensions), just supporting one
> single namespace (ISO-4217).
> we define the interface for MonetaryAmount and provide an implementation
> based on BigDecimal, with all the of(XX) factories on it and what else is
> required. I assume BD is currently a feasible way to go, though we know that
> it is not sufficient for all usage scenarios.
> we define the arithmetics and the precision handling and the serialization
> As we know already that will fit well for simple usage scenarios, the more
> complex ones must be defined outside of SE, since it makes not sense to
> build these aspects in stone, so
> in the EE part:
> we define the other (extended) things, such as
> API/SPI for multiple numeric representations.
> API/SPI for custom currency support
> API/SPI for currency historization
> API/SPI for currency exchange
> API/SPI for extended formatting
> API/SPI for extensions (if needed at all)
> Or we throw away completely the SE restrictions and focus directly on...
> Variant 2: Leaving SE for EE:
> GO for an EE specification leaving SE as is also has its advantages:
> the current JDKs classes can easily be adapted (as they are adapted in our
> current RI), so we can introduce the concepts here for several JDKs, e.g.
> starting from JDK 7.
> the main behaviour can be modelled and defined by interfaces as of now,
> leaving much more details to the implementations. This would us also allow
> to easily provide the flexibility that has shown to be required by many of
> the real world use cases (see attachment).
> At a first look, this looks like a complete off-topic. But when a think
> about our sometimes really ugly discussions here, it may be worth to think
> about. Both variants would allow as to focus on the requirements specific to
> SE/EE. Also since we have seen that it is very difficult to create
> one-fits-it-all solution, we perhaps have to abandon the objective of
> creating a SE implementation that is exactly doing that.
> All variants would us also easily allow to keep in mind (not targeting) as a
> side-effect (indirectly, not explicitly) ME. In all scenarios I do not see
> this JSR will directly be able to provide the ME part by itself. The ME
> colleagues (and Werner ;-)) may open their own JSR and use the stuff defined
> in our JSR as a starting point ;-) When done well the API may look quite
> similar, though it was defined in two separate JSRs.
> We have to agree on this aspects, since this is really crucial! So, all EG
> members are invited to give their opinions on this!
> Anatole Tresch
> Java Lead Engineer, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
> Switzerland, Europe Zurich, GMT+1
> Twitter: @atsticks
> Blogs: http://javaremarkables.blogspot.ch/
> Google: atsticks
> Phone +41-44 334 40 87
> Mobile +41-76 344 62 79