Skip to main content

[JSR-354] General Questions raised by Chris Pheby

  • From: Anatole Tresch <atsticks@...>
  • To: javamoney-list <jcurrency_mail@...>
  • Subject: [JSR-354] General Questions raised by Chris Pheby
  • Date: Wed, 30 Jan 2013 12:13:16 +0100

As already mentioned Chris Pheby has added some valuable comments and questions, which are worth to be discussed also here:

1) Timestamp Modelling:
  • Timestamp modelling: currently ts are modelled as UTC ms timestamps (longs). Unfortunately this not sufficient, since we must be capable of mapping currencies before the 1.1.1970! Additionally returning -1 for undefined is cumbersome, so a null semantic here is a better match. 
  • Whereas currencies typically are defined on day to day basis globally, a plain date (without any timezone would match mostly on a first view, but with virtual currencies there might be additional requirements not yet known.
  • For exchange rates, we require a full timestamp, I propose to use a UTC timestamp. For in SE there must be the according types from 310 used. Any objections?

2) MonetaryAmopunt:
  • Currently the following methods are present for type conversion to SE types:

byte byteValue();


short shortValue();

short shortValueExact();

int intValue();

int intValueExact();

long longValue();

long longValueExact();

float loatValue();

double doubleValue();


Question: should we also add:


BigDecimal bigDecimalValue();


  • Do we really need the method Class getNumberClass(); ? With the methods above, especially also bigDecimalValue() we do not really require access to the internal representation.
  • Rounding: Chris: I don't think rounding is simply a matter of value adjustment. When we chain multiple operations we need a way to define the rounding to be applied. This could be the same across multiple operations, or vary by operation. This implies that operations should be overloaded with the rounding and that a rounding 'mode' could  be associated with the type itself. BigDecimal does some of this, but the rounding is of a limited number of types... the user needs to be able to define the rounding (which the spec has captured).

-> There are good reasons, why we do not want to mix up rounding with the type. For me the question is, if we should add some amount wrapper, which allows to combine a monetary amount with a rounding, so the arithmetic operations performed are always rounded accordingly, e.g.
    MonetaryAmount amt = ...;
    Rounbding rounding = ...;    
    RoundedMonetary rm = RoundedMonetary.of(amt, rounding);

3) Country Modelling
  • Country Modelling: currently currencies also can be accessed by country. The country in this context is modelled by a Locale, e.g. new Locale("","DE");
    Questions:
    - should we introduce a
    Country type, since this would better model a country?
    - should we support only ISO countries or should we also enable namespaces here?

4) Currencies
  • Accessing ISO currencies: since ISO currencies are so widely used, should we provide an additional accessor without namespace, that is using ISO as default, similar to this
    CurrencyUnit usd = Monetary.getCurrencyProvider().get(“USD”);

5) Rounding

  • Should core roundings be accessible via constants (e.g. an extensible enum pattern) ? Currently the RoundingProvider API only defines the following:

public Rounding getRounding(String name); public Enumeration<String> getRoundingIds();

public boolean isRoundingDefined(String id);


6) Serialization
  • What ideas are around, how monetary amounts and currencies should be serialized? The idea behind was that different implementations of MonetaryAmount and CurrencyUnit share a common serialization format to ensure better interoperability.

I think these are the most important points so far (@Chris I am aware that the area of precision as well the exchange rate modelling is missing. I would like to postpone these things.

Regards,
Anatole


2013/1/30 Anatole Tresch <atsticks@...>
Hi Chris

a big thank you for your comments in our spec draft document. I tried to answer most of them, the smaller ones are directly fixed (marked for feedback as needed). Most of the points you noted are quite useful, or points were discussions have stopped or were never done (e.g. the area of exchange was never discussed).
Many of your remarks are very detailed and good starting points for further discussions, so I will try to create a short summary to the EG mailing list, so we can go ahead here also.

Regards and thanks!
Anatole


2013/1/29 Chris Pheby <chris@...>

Anatole,

 

Apologies for being quiet for a while, other commitments have kept me busy in the past few weeks.

 

I’ve updated the EDR draft with some comments, and just pulled down the updated GitHub sources. Hope to get more involved in the coming weeks.

 

BTW I’m in Singapore, so the timezone here is UTC+08:00.

 

Regards

 

 

Chris

 

From: Anatole Tresch [mailto:atsticks@...]
Sent: 29 January 2013 22:26
To: javamoney-list
Subject: [JSR-354] Scope Discussions about JSR 354

 

Dear Colleagues

 

I want to summarized things discussed as follows:

  • I think there are two main visions: defining all by interfaces and provide some arbitrary RI implementation, or define strong value types and add functionality around it as required. The concept of strong immutable value types for the SE environment makes sense and must be considered. But generally I do not think that these two concepts must not be seen exclusively. This also gives us time to check back things with some representative architect from Oracle what must be considered effectively (@Stephen: would you create the contact or should I go via PMO or OpenJDK core mailing list ? ).
  • Nevertheless I do not agree that the value types must be the starting point of thinking. I believe discussing on the interfaces - as we have done now for some weeks - allows us much better to focus and what we really require to model our use cases. Be honest, looking at the discussions from last year, I do not see similar focus on functionality as we have had during the last weeks. Aspects such as separating parts in a SE and some other part or moving some factory methods to some Money type is really not more than 1 day work (plus 1 day spec adaptions). So I want to let this topic now rest as it is for the moment and focus again strictly on the functionality (primarily interface driven).
  • ME is not mainly in focus of this JSR. Basically as I mentioned in a mail I think, we have enough to discuss on the SE part. If, of course, our work is useful for ME, then this is great. But I think that porting this JSR must be done in a separate ME targeted JSR.

 

Additionally, I would like to ask applying for the following rules:

  • This expert group is discussing the Java Money JSR. It can not be that it is argued on other specs, like 310. I am not against to take some examples from other JSR's as explanations, but always with a polite sense in mind and "output". We really have to solve some complex questions here and all experts have their well approved background. So I really would like to encourage all of you to actively create a good atmosphere here. Without that good solutions and discussions will probably never be possible.
  • Finally if you raise a new discussion topic, please ensure that a new subject line is entered, so the discussions can be better separated out, both for us internally, as well for the observers following us.

 

So I hope we can now refocus on discussing formatting and parsing... (a mail thread started by me about some days ago).

 

And again I would like to ask, if we should meet for a Google hangout, so we can get also visually in contact. For setup of a hangout I kindly ask for your preferences in time, so I can send a schedule.

I think the JCP meeting in May in Zurich may also be an option, but I think it would be better not to wait until then.

 

If I did miss anything let me know ;-).

 

Thanks and have a nice time.

 

Cheers,

Anatole

 


 

--

Anatole Tresch

Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

 

Switzerland, Europe Zurich, GMT+1

Twitter:  @atsticks

Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79




--
Anatole Tresch
Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter:  @atsticks
Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79



--
Anatole Tresch
Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter:  @atsticks
Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79


[JSR-354] General Questions raised by Chris Pheby

Anatole Tresch 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Werner Keil 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Anatole Tresch 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Werner Keil 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Anatole Tresch 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Werner Keil 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Werner Keil 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Jeremy Davies 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Werner Keil 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Werner Keil 01/30/2013

[JSR-354] Re: General Questions raised by Chris Pheby

Anatole Tresch 01/30/2013
 
 
Close
loading
Please Confirm
Close