Skip to main content

[JSR-354] JSR 354 API Update

  • From: Anatole Tresch <atsticks@...>
  • To: Jsr 354 JavaMoney Public Mailinglist <jcurrency_mail@...>
  • Subject: [JSR-354] JSR 354 API Update
  • Date: Tue, 25 Jun 2013 09:11:44 +0200

Dear All

Have once more a look to
https://github.com/atsticks/javamoney

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 to
   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, codes
      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
CurrencyValidity
      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 data,
   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

-- 
*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*

Attachment: JSR 354 - API Docs.zip
Description: Zip archive



[JSR-354] JSR 354 API Update

Anatole Tresch 06/25/2013

[JSR-354] Re: JSR 354 API Update

Werner Keil 06/25/2013
 
 
Close
loading
Please Confirm
Close