Skip to main content

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

  • From: Anatole Tresch <atsticks@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: General Questions raised by Chris Pheby
  • Date: Wed, 30 Jan 2013 15:31:06 +0100

Hi Werner

some point from my side:
1) Timestamp Modelling:
All you write is not wrong, for me we do not have to go for 310, but we must at least defines something similar as what is in 310, when we want to provide backward compatibility capabilities. A long UTC timestamp may be appropriate, but we have to implement perhaps the arithemtics ourself to come to an correct day, month, year etc. value, since java.
As an example look at the following snippet:
Calendar cal = Calendar.getInstance();
cal.setTimeInMillis(Long.MIN_VALUE);
System.out.println("Y: " + cal.get(Calendar.YEAR));
System.out.println("M: " + cal.get(Calendar.MONTH));
System.out.println("D: " + cal.get(Calendar.DAY_OF_MONTH));
System.out.println("--");
cal = Calendar.getInstance();
cal.set(Calendar.YEAR, -1500);
System.out.println("ms: " + cal.get(Calendar.MILLISECOND));
System.out.println("Y: " + cal.get(Calendar.YEAR));
System.out.println("M: " + cal.get(Calendar.MONTH));
System.out.println("D: " + cal.get(Calendar.DAY_OF_MONTH));
Result is completely inapproriate:
Y: 292269055
M: 11
D: 2
--
ms: 436
Y: 1501
M: 0
D: 30

Which is completely bullshit. I also tried also with other values and I could go back to until somewhere around 1520. It will be completely impossible to map any values before. So we require here an alternate data type.

2) MonetaryAmount
> 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.
The idea is clearly not to expose the internal representation. The idea is to support conversion to a BD from an amount implementation that may be implemented completely different.
But I also see it rather critical, just wanted to check back, IMO also it is not required, but I still would keep the asType(Class) method since it also can be used for customizations usable for example for mapping of amounts to internal legacy datatypes.

3) Country Modelling
> 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.
OK, seems useful to talk with them, we have multiple topics there. Let us see, what is possible. Nevertheless we have also a Region  ype in our JSR, which matches not to a country, but could also be used as such, if no Region type can be added to java.util.

4) Currencies
> 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)
I agree that the facade design may underlying some change later. But this is not the point of my question. The question was: should we, for convenience, provide a get method (or a of-method), which allows creation of ISO CurrencyUnits, without having to define the ISO namespace explcitily.

5) 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?
On interface level I could imagine also extension. On the implementation level for sure not, since it would break immutability requirements.

6) Serialization
> There should be a good reason, interfaces in public APIs like 310 and others don't simply extend Serializable, nor others like Comparable.
That was never intended.

> 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.
So I try to be more clear: the question is, if should define the serialization format. Of course, we will require from the spec/javaDoc that implementations must be seriazable/comparable and the TCK should also check that.
The question was if we should additionally define how a value must be serialized, e.g.
- two longs for the decimal parts (the first one also containing the sign)
- the internal precision (int)
- The implementation class (String)

The current spec makes a proposal about this, which is already marked as not optimal, or inappropriate. But before starting a discussion on the format, we have to decice, if we want to define explicitly a format at all or just define what values must be serialized, but leave the concrete format to the implementations.

So now I will stop for some times, leaving space for other opinions ;-)

Regards
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


[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

[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
 
 
Close
loading
Please Confirm
Close