Skip to main content

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

  • From: "Tresch Anatole (KFSC 225)" <anatole.tresch@...>
  • To: <jcurrency_mail@...>
  • Subject: [JSR-354] Re: General Questions raised by Chris Pheby
  • Date: Thu, 31 Jan 2013 16:27:41 +0100

Hi Chris

 

To point 2)

The specification REQUIRES explitly that <T> T asType(Class<T>) must support also java.lang.Number (and ubstypes) and java.math.BigDecimal. This will also must be tested by the TCK.

So the only thing is that it not modeled explicitly similar to the methods already in place.

 

Basically, JIRA is good place, since it allows to focus on different area and is for sure more organized than a mailing list ;-)

Now also I have admin access on it and will create according components, so also features/requriements/tasks can be organized accordingly.

 

Regards

 

Anatole Tresch

CREDIT SUISSE AG

Information Technology | Java Core Framework & Support, KSXK 23

Zollstrasse 20/36 | 8070 Zürich | Switzerland

Phone +41 44 334 03 89

anatole.tresch@... | www.credit-suisse.com

 

From: Chris Pheby [mailto:chris@...]
Sent: Thursday, January 31, 2013 16:19
To: jcurrency_mail@...
Subject: [JSR-354] Re: General Questions raised by Chris Pheby

 

Anatole, Werner,

 

Thanks for your follow-up.

 

1)      Timestamp Modelling

 

My feeling is that SE/EE only is a reasonable price to pay for usable temporal types, and my personal feeling (gazing into the crystal ball) is that the capabilities of SE embedded type devices will continue to grow in many domain. For Java prior to 8, I would be willing to accept a (not 100% compatible) backport of the RI.

 

2)      BigDecimal.

 

I guess the driver behind my original thought is that we only directly expose floating point types as complete (exported) representations, or the discrete components, otherwise you are dependent on the implementation capabilities (for BigDecimal) not the specified API. I guess in part this comes down to how much we want to scale down to embedded again. I guess we need to form a definitive point of view on this. For me general purpose usability trumps the embedded case (consistent I think with our low-latency financial is not a core concern starting position)

 

Quite of the few of the other points look like they could be logged to Jira to be considered when the Java core becomes stabilised? Is this the right approach?

 

Regards

 

 

Chris

 

From: Werner Keil [mailto:werner.keil@...]
Sent: 30 January 2013 20:08
To: jcurrency_mail@...
Subject: [JSR-354] Re: General Questions raised by Chris Pheby

 

Anatole,

 

Thanks for the message.

On Wed, Jan 30, 2013 at 12:13 PM, Anatole Tresch <atsticks@...> wrote:

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?

Java Batch JSR has exactly the same decision regarding Minimum Java Version to support, for backward compatibility of the standalone version (aside from taking part in the Java EE 7 Umbrella) with earlier Java versions, they decided NOT to use features of SE 7 like AutoCloseable (allowing try-with-resource from SE 7)

 

We have to ask exactly the same question, and maybe Anatole/CS know that best, if SE 7 or even 6 should still work with JSR 354. The way(s) it'll be distributed even on the SE/EE side are not yet written in stone, and unless an SE 9 JEP or sub-project is accepted, this is still a "standalone" JSR anyway.

 

So do we want to have the Minimum Version of SE 8 (and SE/EE only, at the moment, there is no evidence, 310 will ever even make it into SE Embedded due to its size and anti-modular design) or be open to at least SE/EE 7, too? If so, 310 is an absolute No-Go, and only java.util.Date and similar objects acceptable.

 

 

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();

 

 

JSON JSR had a similar conflict, but there most values are driven by the underlying datatype, so it doesn't reproduce most of BigDecimal/Number methods, but have a bigDecimalValue() if the data type is BigDecimal or a longValue(), probably a Long class, not primitive, for other types, e.g. Integer vs. Floating Point Decimal.

 

I would not do this, otherwise a getValue() or similar method returning BigDecimal seems better

(at least for SE, the Spec should probably say Number or <N extends Number>, and the final value class can override it with BigDecimal, works perfectly fine and does not force an incompatible type into the abstract interface, if you are in SE, then referencing a variable directly by the "Money" type would be acceptable in many cases, also see java.util.Currency) 

 

Having all the primitive getters and a BigDecimal one degrades primitives to "convenience methods", essentially for a BigDecimal based SE (RI) class these would simply return BigDecimal.longValue(), which you can also do yourself in your app if you need it.

 

The dozens of redundant methods in 310, e.g. getInMillis(), getInNanos() beside get(TemporalUnit) or similar are a point of critique from Oracle Architects they are likely to remove those from SE 8, so we should not add too many variations or convenience methods here either. 

 

So the options are

  1. mimick BigDecimal
  2. return BigDecimal at least in compatible environments

 

  • 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);

 

If RoundedMonetary like LocalizedMonetary was an extension to base interfaces like Monetary(Amount) we use here as discussion basis, I am not sure, if the "composition over inheritance" paradigm may not be violated by having to many "behavioral extensions" to such base interfaces?

 

Without too much peeping into 310, one could easily extend Temporal and add isWorkday() or something similar to such sub-interface. Of course, the Temporal implementations like DateTime may not work, but if people started with custom-implementations of "java.time.temporal", this sure would

 

 

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?

 

Similar with Region which ICU4J already adopted following regular updates to the Unicode Standard. 

SE 8 does some Unicode adjustments for Unicode 6, but as of now, I doubt, they plan a java.util.Region in addition to java.util.Locale. 

 

IMHO this really would have to go with the i18n team at OpenJDK. Either enhancing Locale beyond what they already tried so far, or proposing a type like Region, Country or whatever. I would try to keep that out of the "Spec" and only use it in implementations where e.g. Java 8 makes it available.

 

  •  

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”);

 

I am not entirely sure, if the static facade will remain. If value classes like Currency (or an equivalent for now) or Money are more relevant, then the facade idea similar to what e.g. BeanValidation JSR has, could become irrelevant. And factories for CurrencyUnit or MonetaryAmount mainly end up in those classes like

Money.valueOf(), Money.of() (for Money we'd be free to adopt naming patterns, 310 first introduces into the JDK, for Currency we must remain compatible to what's already there, thus getInstance() with e.g. alternate arguments like namespace is likely the only way to go, I don't want to see confusion by 3 different patterns in 1 class, and neither does Oracle)

  •  

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);

 

 

Whether we like it or not, this may replicate at least 2 aspects of Rounding, JDK already has. One older set of numeric constants in BigDecimal, and the new RoundingMode enum, intended to replace those, but for backwards compatibility, we probably still see them in Java 11

 

Not entirely sure, if a JEP for that might be desirable, but at least Victor initially had that in mind. 

Especially the RoundingIds seem somewhat similar to RoundingMode, probably more discussion is helpful here, where this is best placed, java.math (if feasible) or elsewhere.

 

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.

 

 

 There should be a good reason, interfaces in public APIs like 310 and others don't simply extend Serializable, nor others like Comparable.

 

The Temporal JavaDoc probably shows how this could look like for both:

This interface places no restrictions on implementations and makes no guarantees about their thread-safety. All implementations must be Comparable.

 

Putting something similar, also with Serializable where we find it to be relevant (and every implementation of 310 Temporal also does implement it) into JavaDoc seems the best way to go, but if even "value object" JSRs like 310 in the JDK don't add it to the common interfaces, there seems to be no need in the Spec.

 

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.

 

 

Precision and exchange rate modelling may in come areas have influence on the Spec and Public API, but on many others there are specific to RI. Either here in the mailing list, or start creating JIRA tasks for areas we agree should be tackled, this should be differentiated.

 

JIRA (I can help you Anatole with config if needed, there are other JSRs or cases where I need to work with it a lot) has the notion of "component", this is a perfect place where we can tell "Spec/API", "RI/Implementations" or "TCK" apart.

 

 

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


Regards,
--

Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather

Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDR

Skype werner.keil | Google+ gplus.to/wernerkeil

 

* Nordic Java NightHacking: January 31 2013, Copenhagen, Denmark. Werner Keil, JCP Executive Committee Member welcomes Stephen Chin's "Nordic NightHacking Tour" in Copenhagen

 

* Social Media Week: February 18 2013, Hamburg, Germany. Werner Keil, JCP Executive Committee Member, Agorava Co-Founder will present "Enterprise Social using Open Source Frameworks like Agorava"



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

(continued)

[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

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

Werner Keil 01/30/2013

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

Chris Pheby 01/31/2013

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

Sascha Freitag 01/31/2013

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

Jeremy Davies 01/31/2013

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

Chris Pheby 01/31/2013

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

Tresch Anatole (KFSC 225) 01/31/2013
 
 
Close
loading
Please Confirm
Close