Skip to main content

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

  • From: Chris Pheby <chris@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Subject: [JSR-354] Re: General Questions raised by Chris Pheby
  • Date: Thu, 31 Jan 2013 15:27:07 +0000
  • Accept-language: en-GB, en-US

Hello,

 

As far as I can see the Temporal type does not carry a null payload (or equivalent magic number) but for nullable values I don’t think magic numbers are the right approach.

 

I am aware of the performance counterpoint, but in practice other than (e.g.) autoboxing/unboxing in a loop I do not think this is a concern that trumps API usability in general. My feeling is that we should start with the cleanest possible API and then optimise selectively.

 

Regards Chris

 

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

 

Thanks.

 

Not sure about those who prefer primitives over objects for performance reasons for now?

 

Over time, Java 10+ is likely to merge these anyway, but at the moment, both java.util.Date and from what this tells http://cr.openjdk.java.net/~rriggs/threeten-javadoc/java/time/temporal/Temporal.html also relevant interfaces of 310 use long primitive type. 

 

Werner

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

I think we can stop the discussion here. The only thing to think about, is if should use a Long instead of a long, so we do not have to return -1 if a timestamp is not defined (we then would introduce a null semantic, returning null, instead of.

 

Regards,

Anatole

PD: The results before were correct. You additinoally have to evaluate the era on the calendar, Long.MIN_VALUE maps to 292269055 BD (not AD) ;-). That is more or less Trias, so I assume this is sufficient ;-)

 

2013/1/30 Werner Keil <werner.keil@...>

What is wrong with java.util.Date then?

 

Also if you get SQL dates those are direct subclasses of java.util.Date 

Hence it'll take several SE and EE versions until JSR 310 is even remotely adopted, we hope and wish Stephen the best, but examples of java.util.logging showed, that sometimes stuff the JDK got was simply ignored and nobody used it, and of course having java.util.Date in 99% of all possible platforms (ignore JavaCard for now) as opposed to only a "Full SE" with limited or no EE support until EE 8 or even 9/10 for JSR 310


Regards,

Werner

 

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

Hoi Werner

 

Calendar cal = Calendar.getInstance();

cal.setTimeInMillis(Long.MIN_VALUE);

-> Year = 292269055

 

That was JDK 7. Perhaps that usage is naive, but I would expect something like: -4716 equaling to 4716 BC, as described in your mail, or an IllegalArgumentException. For me the fact, that this is not the case, let me make think if there are alternatives. Mainly we do not need the calender arithmetics, we only need a valid data representation (a value type!).

 

Other opinions?

 

Regards,

Anatole

 

2013/1/30 Werner Keil <werner.keil@...>

Hi Anatole/all,

 

Thanks for the quick response.

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

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.

 

I created Calendar improvements and extensions as far back as 1997 (just after Java 1 came out, no evidence of Joda, which according to SF.net started 2002 then) in a SF project called SDJ (Survey Developer Library 4 Java). Open Sourced on SF by 2001 after it was used for numerous clients and projects internally.

 

One of the challenges were custom durations, along the line of what 310 added very recently, QUARTER_OF_YEAR, HALF_OF_YEAR, or others like "fortnight", often commercially used by British banks and businesses at least, guess that's why 310 hasn't got it, given UK is not 80% of the World any more?

 

There are multiple getters, setters and other method calls, can't tell you of the top of my head, but there are things e.g. the SDJ custom extension of GregorianCalendar (compatible with java.util.Calendar base class despite all of its quirks) had to do, before e.g. a quarter or other duration was calculated correctly, including all the other fields you mentioned.

 

As a Spec the JSR cannot rely on things that are not wide enough part of the Java Platform already, and that even in Java 8 only a small (considering the number of runtimes or CPUs/cores if you want, SE Desktop and even EE will play a lesser role) number of Java runtimes will come with.

 

For implementations, this could be done by using 310, should that address all the problems you mentioned (maybe someone best created a Unit Test or similar test case for these requirements?) for implementations under Java 6 or 7, I'm afraid, the only alternatives could either be JodaTime, that "Backport" of 310, or similar.

And given none of these have even the slightest chance of a common basis, we would have to use Generics to avoid API with incompatible types. Java itself and all parts like Lambda do that everywhere. 

The only other alternative would be long values to capture e.g. a Timestamp. 

 

Btw, if you look at a page like this:

It states:

The current implementation handles dates in a wide range, from 4716 BC up to 5000000 AD. Dates outside of that range will throw an IllegalArgumentException. This range should be broadened in the future.

 

Although much of the JavaDoc got lost in recent JDKs, I doubt, the functionality was seriously broken, so the first year you can handle with Calendar (if you adjust ALL fields properly) is clarly not 1520.

 

Does 4716 BC till 5000000 AD sound, like we can't live with that?

 

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



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"



 

--

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] Re: General Questions raised by Chris Pheby

(continued)

[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

[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