Hi Stephen /all
I think that the money API is an order of magnitude simpler than JSR-310.
-> I do not agree here, read ahead...
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
- Currencies are the units, but as we have seen there are multiple units. Some may model the same thing in reality, some may model completels different things. Also there is no clear and simple relation between different types of units/currencies. Even not between the same type of units (e.g. real world leagal tendered currencies).
- Additionally currency (also ISO currencies) are defined only within a certain time range. For different timestamps you have different currencies (also ISO allows to have the same code theoretically being reassigned within a certain time period).
- Additionally ISO Currency codes are not always unique (there is a code defined for a African state union, where there are different legal tenders mapped to the same ISO code), similarly there are for the same currency (US dollars), multiple codes USD, USS, USN.
- As a third dimension the exchange rates to be applied also are highly complex, they depend
- on the target timestamp
- on the concrete contract in place for the use case
- the location where the exchange transaction should be performed
So there is no simple case of just multiplying two amounts together. As seen above equality for currencies is more than simply comparing two Strings.
Additionally when you remember on our discussions about arithmetic precision this is also not trivial.
I really would appreciate if this complexity here is not underestimated. Of course, one can say, we want to ignore it. But in that case that looks like ignoring timezones in datetime, to make the bridge to 310.
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
[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED
|Tresch Anatole (KFSC 225)||01/29/2013|