Skip to main content

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

  • From: "Jeremy" <jerdavies@...>
  • To: <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED
  • Date: Tue, 29 Jan 2013 10:57:33 -0000

Hi Anatole,all,

 

Having read the arguments I’m coming down on the side of:

 

> Variant 1: Separation into a SE and EE part:

 

This, IMO, gives us a clear seperation that will allow us to create simple, elegant SE impl and then build out the more complex use-cases into SE, as you pointed out.

 

That said, due to the use of BigDecimal as the value type would this then mean that the ME impl would have to branch off in a different direction?

 

 

 

From: Tresch Anatole (KFSC 225) [mailto:anatole.tresch@...]
Sent: 29 January 2013 10:02
To: jcurrency_mail@...
Subject: [JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

 

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.

 

Regards,

Anatole

 

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

happens)

 

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

work.

 

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.

 

Stephen

 

 

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

> format.

> 

> 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!

> 

> Regards,

> 

> --

> 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

(continued)

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Anatole Tresch 01/28/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Jeremy 01/28/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Anatole Tresch 01/28/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Stephen Colebourne 01/28/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Tresch Anatole (KFSC 225) 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Stephen Colebourne 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Werner Keil 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Werner Keil 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Stephen Colebourne 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Werner Keil 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Jeremy 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Werner Keil 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Jeremy 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Werner Keil 01/28/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Werner Keil 01/28/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Anatole Tresch 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Stephen Colebourne 01/29/2013

[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED

Jeremy 01/29/2013
 
 
Close
loading
Please Confirm
Close