Skip to main content

[JSR-354] Re: Validity Dates for CurrencyValidity

  • From: "Tresch Anatole (KGVA 55)" <anatole.tresch@...>
  • To: <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Validity Dates for CurrencyValidity
  • Date: Thu, 8 Aug 2013 18:21:05 +0200

Yes the word abstract is from a former release I think...

 

 

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@... <mailto:anatole.tresch@...>  | www.credit-suisse.com 
<http://www.credit-suisse.com

 

From: Werner Keil [mailto:werner.keil@...] ;
Sent: Thursday, August 08, 2013 17:08
To: jcurrency_mail@...
Subject: [JSR-354] Re: Validity Dates for CurrencyValidity

 

One more thing, the JavaDoc of ValidityInfo says

 
/**
 * This abstract base class models a validity of an item S related to a
 
 * timeline. Hereby a validity may be undefined, when it starts or when it 
ends.

...
but the actual class isn't abstract. Shouldn't it be, or would we rather 
remove the word "abstract" from the doc?

 

Mark (Google) also suggested where appropriate to combine JodaTime and ICU4J 
since there are areas (especially the whole formatting/parsing and natural 
language space) where it's superior to Joda, Holidays where extended business 
or validity rules might use that kind of thing is another important area 
neither Joda nor 310 covers in the foreseeable future. 

 

You barely notice it, and GWT or GAE won't expose either of them, but a 
majority of them even use both libraries under the hood, too 

 

Werner

On Thu, Aug 8, 2013 at 3:49 PM, Werner Keil <werner.keil@...> wrote:

In the implementations, a standalone RI of JSR 354 would still have to 
refrain from something that only becomes integral part of SE 8, but similar 
to LogStash, if it's worth the effort and increased size/complexity, 
including e.g. JodaTime (the whole distro is 10MB  but the actual JSR only 
around 560kb, so compared to the much more powerful ICU4J it's tiny ) why 
not. That 310 "Backport" won't be reliable until the actual Java 8 content is 
out, so if it's inside an implementation and does not affect the public API 
method signatures, I'd probably go for JodaTime.

 

For the public signatures could we try to use only Calendar rather than 
concrete instances like GregorianCalendar. Also long as arguments unless 
there's a method that must return null in this form??

 

Cheers,

Werner

 

On Thu, Aug 8, 2013 at 3:40 PM, Tresch Anatole (KGVA 55) <anatole.tresch@...> 
wrote:

Hi Werner

 

As mentioned in my first email ;-), I did never want to change anything for 
exchange rates or the validity query APIs.

Only for the currency validities returned and thus stored/managed within the 
SPI implementations...

 

Cheers,

 

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 <tel:%2B41%2044%20334%2003%2089> 

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

 

From: Werner Keil [mailto:werner.keil@...] ;
Sent: Thursday, August 08, 2013 15:22


To: jcurrency_mail@...
Subject: [JSR-354] Re: Validity Dates for CurrencyValidity

 

Lots of the new JSON/REST based new APIs you see everywhere in the Web do 
exactly that btw. Also the ones dealing with Money and Bitcoin 

 

The problem is, creating this just for validity and leaving conversion with 2 
longs would make the API almost more confusing than if you went on embedding 
ICU4J here and baked JodaTime into the other one (in the absence of 310, 
that's not an option until Java 8 is both final and widely enough accepted)

 

The validity may find "date" in the sense of Year/Month/Day sufficient, but 
exchange rates if not within milli- or nanoseconds at least change several 
times per day, so that requires a DateTime equivalent.

 

Cheers,

Werner

On Thu, Aug 8, 2013 at 3:15 PM, Tresch Anatole (KGVA 55) <anatole.tresch@...> 
wrote:

If timestamps would be a good model for the use case here, I would not 
discuss it. If I design an SPI and I see that its implementation is 
cumbersome, I think the SPI must be discussed. Even if a thousands of time 
implementations would exist in the JDK, there is obviously no one, that 
really matches our use case here.

This is also the reason, why sometimes date are mapped to Strings, e.g. as 
"12011970"... (which I did and will not propose)...

 

Cheers,

 

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 <tel:%2B41%2044%20334%2003%2089> 

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

 

From: Werner Keil [mailto:werner.keil@...] ;
Sent: Thursday, August 08, 2013 15:09


To: jcurrency_mail@...
Subject: [JSR-354] Re: Validity Dates for CurrencyValidity

 

Yes, but that only captures a UTC timestamp, what value does a wrapper 
interface have here? I'd stick to the long or Long for Beginning and End, 
otherwise we'd overengineer it for the scope of a Monetary API.

 

There are so many frameworks out there, let's face it, more people in real 
business apps use ICU4J (not only Eclipse, a vast majority of Apache projects 
uses it, too, see Harmony, but it won't be the only one) JDK has millis 
almost everywhere, even JavaFX uses them internally (as a "delta" between 
start and end timestamp) while 310 has a combination of seconds and nanos 
(within the duration, otherwise you won't get so far with int)

 

 

On Thu, Aug 8, 2013 at 2:57 PM, Tresch Anatole (KGVA 55) <anatole.tresch@...> 
wrote:

Hi Werner

 

Just to be precise

1)      We talk about LocalDate not Duration

2)      The discussion is API relevant (ext package).

 

Cheers,

 

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 <tel:%2B41%2044%20334%2003%2089> 

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

 

From: Werner Keil [mailto:werner.keil@...] ;
Sent: Thursday, August 08, 2013 14:52


To: jcurrency_mail@...
Subject: [JSR-354] Re: Validity Dates for CurrencyValidity

 

Looking at 2 Duration classes of JavaFX

https://bitbucket.org/openjfxmirrors/openjfx-8-master-rt/src/a01e2111906eba62052571e711ef1c430070fefb/javafx-common/src/javafx/util/Duration.java?at=default

and the 310 BP

https://github.com/ThreeTen/threetenbp/blob/master/src/main/java/org/threeten/bp/Duration.java

 

(almost 3x more LOC for a class that effectively does the same) we'd probably 
best add an implementation of such Timeframe/Duration or whatever we might 
call it interface (just not exactly the same names as in JavaFX or 310 I'd 
say) into the RI. In future (similar to what we prepared e.g. the 
"Functional" interfaces) this could in an SE8+ only environment extend 
TemporalAmount. 

 

Werner

 

On Thu, Aug 8, 2013 at 2:22 PM, Werner Keil <werner.keil@...> wrote:

Hi Anatole,

 

You mostly refer to 
https://github.com/JavaMoney/javamoney/blob/master/money-api/ext/src/main/java/javax/money/ext/ValidityInfo.java

I assume.

 

For starters I would stick to Calendar, not pass GregorianCalendar 
explicitely.

See

http://marxsoftware.blogspot.dk/2013/05/jdk-8-calendar-builder.html
Java 8 has at least as many changes to java.util.Calendar as it did with e.g. 
310 (which only offers the same range of features anyway) plus 
Calender.Builder allows to use 310 Instant type if you're under Java 8 and 
it'll return the same there, so it IS already compatible with 310 that way. I 
don't see much value in adding an interface here, unless (and we had to do 
that under Java 7) we really want to extend java.util.Date or Calendar in a 
way I did with EnhancedCalendar of SDJ 
http://sdj.cvs.sourceforge.net/viewvc/sdj/sdj3/sdj-core/src/java/net/sf/sdj/util/EnhancedCalendar.java?view=markup

 

Allowing to extend GregorianCalendar or any other Calendar this interface in 
SDJ theoretically would allow different implementations like some Joda types 
now, too (while EnhancedCalendar goes a bit further back, first introduced 
around 1996/7)

 

Also the arguments passed to ValidityInfo as opposed to other interfaces may 
be long primitive rather than the wrapper class Long, couldn't it?

 

Regardless of whether we'd stick to UTC timestamps plus Calendar or somehow 
substituted them (having to implement those essentially by extending 
Calendar, Date or both) the wording of "Start - End" vs. "From - To" in 
ValidityInfo should be improved. Especially with conversion and factories 
along the lines of from(), of() or to() I'd find it more easy to distinguish 
if we used getStart() and getEnd() possibly with some type like "Date" in the 
method name, what do you think?

 

To make sense of possible future connections to java.time, only a stub for 
TemporalAmount seems useful, everything else just encapsulates a timestamp, 
even if you used a wrapper around Calendar. 

 

So a ValidityDuration, ValidityPeriod, ValidityTimeframe or something similar 
could be reasonable.

You might use similar tricks as in

  public <C extends Calendar> C getFrom(Class<C> type) {

 

and if the return type was <T extends TimeFrame> this could allow multiple 
implementations of such interface, e.g. one backed by JDK Date or Calendar, 
while other implementations may use JodaTime or JSR 310 in an appropriate 
(SE8+) environment.

 

Having said that, I hope you see the obvious (which is why I called it 
TimeFrame, not ValidityTimeframe) that this "drop-in" for TemporalAmount 
should if we really go down that path also apply to ExchangeRate in the 
"convert" module, not just in "ext" or packages within that module. That'll 
be more consistent, else stick to UTC timestamps everywhere.

 

WDYT?

 

On Thu, Aug 8, 2013 at 1:06 PM, Tresch Anatole (KGVA 55) <anatole.tresch@...> 
wrote:

Hi Werner

 

So summarizing you you would go for the option (which I also prefer):

 

·         write a ValidityDate class equivalent to LocalDate, which could
implement JSR-310 interfaces later.

 

I think the other thing is just a bug, which happens unfortunately, when you 
write software...

 

Regards,

Anatole

 

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 <tel:%2B41%2044%20334%2003%2089> 

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

 

From: Werner Keil [mailto:werner.keil@...] ;
Sent: Thursday, August 08, 2013 13:01
To: jcurrency_mail@...
Subject: [JSR-354] Re: Validity Dates for CurrencyValidity

 

We appreciate the effort, but as I also hear from Oracle in various EG calls, 
no sane company will use Java 8 for another decade Oracle Fusion Middleware 
12c, the brand new "Cloud" series is based on Java EE 6, hence it's Java SE 
6, too (despite what pages like this say 
http://www.oracle.com/technetwork/java/eol-135779.html but if you have ;
licensed either Java SE 6 or bought Fusion Middleware products for Hundreds 
of Thousands of Pounds or Dollars a year, you get support and even patches 
for 20 years, too, if you need, I worked for BEA Support and some of the 
biggest British companies used WLP 4 paying dedicated staff a few Mio. £ then)

 

So JSR-310 could become relevant as soon as Java EE 8 is broader adopted, no 
sooner than that I'm afraid. Baking it into the spec is unacceptable, future 
versions of RI or implementing solutions may do so, e.g. if they use only SE 
functionality.

 

And speaking of its precursor, JodaTime, I just happen to work on a support 
issue in our DevOps team around LogStash. It also uses JodaTime underneath.

 

And using the same DateTimeFormatter LogStash ends up getting at least two 
different kinds of exceptions for the same problem (using "h" instead of "H" 
in some date patterns) one would be

 

java.lang.IllegalArgumentException: Invalid format: "Tue Apr 02 13:47:40 2013"

the other

org.joda.time.IllegalFieldValueException: Cannot parse "Sun Aug  4 13:06:41 
UTC 2013": Value 13 for clockhourOfHalfday must be in the range [1,12]

        at 
org.joda.time.field.FieldUtils.verifyValueBounds(FieldUtils.java:218)

        at 
org.joda.time.field.ZeroIsMaxDateTimeField.set(ZeroIsMaxDateTimeField.java:85)

        at 
org.joda.time.format.DateTimeParserBucket$SavedField.set(DateTimeParserBucket.java:483)

        at 
org.joda.time.format.DateTimeParserBucket.computeMillis(DateTimeParserBucket.java:366)

        at 
org.joda.time.format.DateTimeFormatter.parseDateTime(DateTimeFormatter.java:854)

 

So while JSR 310 fortunately got quite a bit trimmed and simplified thanks to 
Roger and Oracle, it still contains a few of the "maze" JodaTime offers with 
so many different ways to do things that most Open Source projects (or 
commercial companies where they dare to use it) run into similar problems as 
LogStash. You do the same thing, even using the same class and get two rather 
different error messages for the same reason, because your hour is 13:30 
instead of 1:30pm 

 

Not to mention, Java 8 does offer java.text.DateFormat just as well and it 
won't return a Joda/310esque date, or JavaFX Duration. The latter is designed 
mostly for millis to hours, but isn't using 310 either. And as long as JavaFX 
aims to be backward-compatible with either its own older versions or Java 5-7 
it never will be. Theoretically some day it could use the Duration class in 
java.time, but we'll see a lot of time literally pass till this is going to 
happen... If JavaFX ever did, an API like 354 might also consider using 
Duration or the underlying TemporalAmount

 

Werner

 

On Thu, Aug 8, 2013 at 11:55 AM, Stephen Colebourne <scolebourne@...> wrote:

On 8 August 2013 06:35, Anatole Tresch <atsticks@...> wrote:
> when trying to implement regional validity of currencies in the RI I
> encounter a possible issue with our currency validity model, I think we have
> to discuss. The point is that ISO, as well as CLDC sources all model the
> currencies validity in form of a local date (in the sense of 310), so
> without any timezone information. In our model, we currently have the UTC
> from/to timestamps, which for all querying APIs may match well, and IMO also
> make sense for exchange rates. But in case of the validity records for
> currencies, it makes it difficult to implement the SPI, since I have to
> convert each local date for each region/territory, where a currency is
> valid, to an UTC timestamp. In case of big countries with multiple timezones
> this even leads to potential invalid data, since the validity record is not
> constraint to a specified timezone. Additionally I think that for most use
> cases local dates for currency validity is sufficient and also feel more
> natural, so using local dates would match the commonly used way to model
> this, and with UTC we add here unnecessary complexity.
>
> As a consequence this leads to another point: how we should model local
> dates without 310...

Ignoring the obvious response of just using JSR-310, you have various choices:

- use epoch-day, an int/long count of days where 0 is 1970-01-01
- use modified-julian-day, an int/long count of days where 0 is 1858-11-17
- write a ValidityDate class equivalent to LocalDate, which could
implement JSR-310 interfaces later

Stephen

 

 

 

Attachment: image001.gif
Description: image001.gif

Attachment: image002.gif
Description: image002.gif

Attachment: image003.gif
Description: image003.gif

Attachment: image004.gif
Description: image004.gif

Attachment: image005.gif
Description: image005.gif



[JSR-354] Re: Validity Dates for CurrencyValidity

(continued)

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013
 
 
Close
loading
Please Confirm
Close