[JSR-354] Re: JSR 354 API Update
- From: Werner Keil <werner.keil@...>
- To: jcurrency_mail@...
- Subject: [JSR-354] Re: JSR 354 API Update
- Date: Tue, 16 Jul 2013 02:53:16 +0200
The JSR most recently in EDR stage, 302 (check the EDR document here
https://github.com/scj-devel/doc links including the JCP page should be
easy to find) raises quite a few interesting questions. And I hate to say
this, it comes with Yet Another Date/Time API this time for Real-Time
precision, down to nanoseconds.
While Safety Critical in the strongest sense could be hospital
life-support, avionics or similar, this Canadian Research Fund (around the
time, some of the JSR 302 codebase was last updated[?])
http://www.eng.mcmaster.ca/news/news2009/safety_software.html highlights a
few business-critical aspects like "banking transactions, financial
reporting" as safety-critical, too.
We heard arguments about the scope of JSR 354, and while it may build on
the first JSR ever (JSR 1) for Real-Time aspects, beside the "Critical"
environments it hopes to support there are also a lot of Real-time aspects
to it. Projects related to it, (oSCJ) do not always look like they're
strictly CLDC or Java ME Embedded (though the original proposal said J2ME),
the hardware like BeagleBoard, more commonly runs Java SE Embedded. And
references to Java 8 Checker Framework (based on JSR 308) unless this was
only for development environments, also suggest the runtime could equally
be more SE than ME Embedded.
So one may find SE Embedded (which Roger said, normally contains both
java.util.Date,... and java.time in version 8, not to mention the separate
Duration API if there's JavaFX,too) used with such JSR in Real-time
Financial apps, where a timestamps may come from 7 different sources
including System.currentTimeMillis() if you take AbsoluteTime and other JSR
302 classes (which may of course produce most reliable results in such
environments[?]) into consideration. JavaFX Duration is a bit of an odd
fellow, given it uses *double *for all relevant primitive values like
millis or nanos, all other APIs including JSR 302 or 310 return *long*, so
with the current choice we seem to be on a very safe side.
On Tue, Jun 25, 2013 at 9:11 AM, Anatole Tresch <atsticks@...> wrote:
> Nevertheless I am still thinking how we can best model the time aspects,
> especially for historic access. Some of the reasons are:
> - In ISO 4217 the validity for currencies is also defined, but the
> definition there would better match to 310's LocalDate than a UTC
> timestamp. Using UTC timestamp forces as to convert all time related
> e.g. for the validity of a currency within a country, to UTC timestamps,
> whereas if we would use something similar to LocalDate this would not be
> necessary (despite some special cases, like big countries with multiple
> timezones...? ). Regarding this I feel, we have to further look for a
> better solution, such as defining a money related ValidityRange.
> Within ValidityRange we can encapsulate the additional logic needed
> and also support *local *date/time information. Also ValidityRange can
> easily extended in a JSR's maintenance release to fully
> support/interoperate with JDK8 temporal units.
> These aspects I did not yet have time to make a proposal. If someone
> of you want to make one - you are welcome.
> Regards and have a nice day!
> *Anatole Tresch*
> Java Lead Engineer, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/*
> *Google: atsticks
> Phone +41-44 334 40 87
> Mobile +41-76 344 62 79*
Description: GIF image