[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, 25 Jun 2013 13:56:30 +0200
Thanks, looks good and at least about nearly all 4 (except Sacha, but it
seems he even deleted his GitHub user, or just created one under a
different name?) who contributed to the main API code-base so far
https://github.com/atsticks/javamoney/graphs/contributors also joined the
Hangout 10 days ago.
It's no longer at GitHub and also (except for a written Spec document we
might be presented some day just to avoid it becoming dormant or withdrawn[?])
sorry Thomas, not a JSR, but the stats of what used to be 310 on GitHub
https://github.com/ThreeTen/threeten/graphs/contributors speak a clear
language. There were just 2 people contributing code between 2007 and 2012,
and of them 95% was just a single user, 5% the other "Co-Spec Lead". This
should look different in OpenJDK now, but I don't bother looking there.
Again, this is not to compare this JSR with another (ex) JSR, only to show,
who has been actively involved and that some "Functional" or "Domain
Specific" JSRs along the line of 354 also mainly received contributions
from very few, sometimes just a single domain expert. Thanks to GitHub's
new reporting you could also look into other JSRs like CDI or
BeanValidation, where the API was just maintained by 3 people:
Of course it's a 1.1 release, so the total number of commits and code may
not be comparable to 354 which is aiming for 1.0.
On Tue, Jun 25, 2013 at 9:11 AM, Anatole Tresch <atsticks@...> wrote:
> Dear All
> Have once more a look to
> or the according JavaDocs attached (@Mark - you should now receive this
> email ? )
> Summarizing I propose the following changes:
> - I removed currency aspects from the MonetaryRegions, so regions are
> per se standalone and no concerns are mixed up anymore). This allows us
> directly model regions, territories and also ISO countries independent of
> any currency logic that uses it).
> - I separated the functionalities in MonetaryCurrencies so
> - The main methods on the MonetaryCurrencies singleton are not
> historized and simply give overall access to all defined namespaces,
> and currencies. This API makes it simple to handle and add additional
> currencies and allows also for a lean SPI, which must not care of
> historization aspects.
> - Similarly to what I've been proposed one week ago, I added a
> service which can be accessed for different sources, one of them
> e.g. CLDR.
> For me so far this makes sense and also has resolved some TODOs in the RI,
> which obviously were there because the design was not appropriate ;-)
> 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