Skip to main content

[JSR-354] CurrencyData (was Separation of Validity)

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Cc: Mark Davis <mark@...>
  • Subject: [JSR-354] CurrencyData (was Separation of Validity)
  • Date: Sun, 9 Jun 2013 18:59:36 +0200


Thanks to some of the Adopt-OpenJDK guys and their efforts there are Git clones of the recent Java 8 codebase, see
as well as an earlier Java 7 version:

If you compare the two, you'll notice, Java 7 had some "historic" validity information like 
for Venezuela and a few others, while Java 8 seems to contain no such thing.

We should hook up with the i18n team to find out, why this was removed between version 151 and 154 of the data set, and whether the reason is, Oracle/OpenJDK does not consider that relevant enough any more?

Above examples show, it was maintained using standard means of the JDK, even though in most cases you would not have direct access to it.
Most likely, if the system date was before 2008 for Venezuela, you'd simply get the old currency, which by now JDK considers irrelevant. 

Bugs like this 
show there are still changes and at least the Java 8 version of seems to not take it into consideration.

There is of course at least one more:

It contains plain text "metainformation", but no relevance as a date or year.

An internal helper class for CLDR can also be found there:

However, it seems, JDK classes related to currency so far don't use CLDR directly. 
Given the cutover date can be used by java.util.Currency, via a, it just isn't exposed, it seems best to remain compatible with that where we can. With the difference of exposing such cutover date via the API. 

If separating this into 3 interfaces or classes (CurrencyUnit, Displayable and either Validatable or something else) does not confuse people, it seems fine, given at least CurrencyUnit and Displayable are usually bound together in a concrete class like java.util.Currency or similar implementing classes.

What isn't part of java.util.Currency right now, we should find an approach that is similar to what Mark proposed, but compatible with that Java i18n got so far.


On Sun, Jun 9, 2013 at 5:37 PM, Werner Keil <werner.keil@...> wrote:

Thanks for the concrete code proposal.
The boolean getter for tender probably should be isTender() or similar. 

While it may be a little late for Java 8, it looks like the i18n team at OpenJDK thinks about tweaking currency data, especially that one may apply for ad-hoc changes to currency information:

However, we should communicate with Naoko and others in the i18n team ASAP.
While it may not make sense for Java 8 to add some of the information discussed, it is in everyone's interest to add such information to later versions or even Updates of Java 8 (things like JavaFX were added to Java 7 in a MR rather than waiting all the way for SE 8, technically some of that could be added to 8 at a later point if there is an equally good reason for it) in a compatible way that doesn't break what they're just adding right now.

About immutable classes or interfaces, this note at EclipseLink, the JPA RI also sounds quite interesting, while we may explore, whether CurrencyUnit could also be used in such an adapter or MonetaryAmount to marshal the entire monetary value


On Sun, Jun 9, 2013 at 5:12 PM, Mark Davis ☕ <mark@...> wrote:
I agree with separating out the validity checks from the currencies. As to the precise form that takes, I suggest a class (name TBD), with a factory method that returns a concrete class that has the CLDR data for currencies. The two main requirements are: 
  1. for a region (country code), find the currencies and periods in which they were valid;
  2. for a currency, find the countries in which it was valid (and for which periods).
So you could do something like:

CurrencyValidityData myCurrencyInfo = CurrencyValidityData.getInstance("cldr");

for (CurrencyValidity info : myCurrencyInfo.getInfo(CurrencyUnit.getInstance("USD")) {
// would cycle through the regions in use, eg for USD: Haiti (HT), Panama (PA), U.S. Virgin Islands (VI), Caribbean Netherlands (BQ), Zimbabwe (ZW), Ecuador (EC), Northern Mariana Islands (MP), Diego Garcia (DG), El Salvador (SV), U.S. Outlying Islands (UM), Guam (GU), Palau (PW), Puerto Rico (PR), American Samoa (AS), British Indian Ocean Territory (IO), Micronesia (FM), United States (US), British Virgin Islands (VG), Turks and Caicos Islands (TC), Timor-Leste (TL), Marshall Islands (MH), Cuba (CU), Dominican Republic (DO)

  CurrencyUnit unit = info.getCurrencyUnit(); // constant USD in this case
  String region = info.getRegion(); // eg US or TC
  long from = info.getFrom(); // eg 1792-01-01 00:00 or 1969-09-08 00:00; MIN_LONG if no known start date
  long to = info.getTo(); // eg MAX_LONG  if no known end date
  boolean tender = info.getTender(); // eg true


for (CurrencyValidity info : myCurrencyInfo.getInfo("RS") {
  // would cycle through the CurrencyUnits for Serbia: eg RSD, CSD, YUM

The info could also have:
  int decimals = info.getDecimalDigits(); // eg 2
  int rounding = info.getRounding(); // eg 0
  int cashRounding = info.getCashRounding(); // eg 5

The stock info could have a getInstance for "cldr". We could have methods so that others could be registered, and you could find the available ones.

— Il meglio è l’inimico del bene —

On Sat, Jun 8, 2013 at 8:39 AM, Anatole Tresch <atsticks@...> wrote:
Deaar all

I was thinking about, how we can separate Validity from the instances, e.g. CurrencyUnit (one of the key feedback points out of the EDR). As attachment find my proposal how we can achieve that:

  • The Validity value type defines a validity for any item where it can be used: CurrencyUnit, but also ExchangeRate.
  • I defined another interface Validateable which can be implemented by classes that support validity ranges. I suggest hereby that
    • CurrencyUnit will NOT extend this interface. Basically this leads to a very lean CurrencyUnit, which basically only extends the current Currency class by namespaces, the general legal tender and virtual flags (see also attached interface). As a side effect the implementation of equals/hashCode also gets simple.
    • ExchangeRate would implement this interface.
    • Additionally for the MonetaryCurrencies singleton, within the ext package a ValidatedCurrencyUnit class can be implemented that extends CurrencyUnit with Validateable.
    • Similarly a ValideatableAmount class can be added that combines validity with a MonetaryAmount.
I know that not all details were worked out, but I think, it is worth starting the discussion given the two interfaces attached and the comments above. So the discussion is open!


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


Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather

Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #OpenDDR

Skype werner.keil | Google+

* Eclipse DemoCamps Kepler 2013: June 19-28 2013, Germany, Denmark, Austria. Werner Keil, UOMo Lead, Mærsk DevOps Build Manager will present "Triple-E’class DevOps with Hudson, Maven, Kokki, Multiconf & PyDev", "M4M 2 the Rescue of M2M"

[JSR-354] CurrencyData (was Separation of Validity)

Werner Keil 06/09/2013

[JSR-354] Re: CurrencyData (was Separation of Validity)

magesh.kasthuri 06/10/2013
Please Confirm