<i18n dev> Currency updates in JDK 7

Mark Davis ⌛ mark at macchiato.com
Mon Aug 24 14:24:00 PDT 2009

The CLDR data has information about usage, such as which countries a
currency is valid in during what period. It is really not as simple as an
association of country to currency, and it would be useful to have an API
that was not only customizable, but capable of returning the right kinds of


  <fractions> // for currency decimals
others, eg:
<region iso3166="AO">
  <currency iso4217="AOA" from="1999-12-13"/>
  <currency iso4217="AOR" from="1995-07-01" to="2000-02-01"/>
  <currency iso4217="AON" from="1990-09-25" to="2000-02-01"/>
  <currency iso4217="AOK" from="1977-01-08" to="1991-03-01"/>

If a currency is not a tender, it is marked, eg:

<region iso3166="ZZ">
  <currency iso4217="XAG" tender="false"/>


On Mon, Aug 24, 2009 at 13:53, Stephen Colebourne <scolebourne at joda.org>wrote:

> Naoto Sato wrote:
>> Stephen Colebourne wrote:
>>> Unfortunately, not all currencies are associated with countries. Some,
>>> like XAG for 'silver', XDR for 'IMF drawing rights' or XXX for 'no
>>> currency' have no matching country. Thus, this file format is unable
>>> to represent user overrides to those countries.
>> You meant "those currencies" here, right?  If that's the case, yes it is
>> true.  We might need these currencies be updated in this properties file by
>> enhancing the file format, however, the frequency for those currencies being
>> updated is much less than the ones associated with particular countries.
> Yes, thats what I meant. For the new Joda-Money I used this file format:
> FJD,242,2,FJ
> FKP,238,2,FK
> XAG,961,-1,
> The last column are the two letter country codes that the currency is
> applicable for (blank means pseduo curency).
>  Right now, there is no mechanism to update the ISO-3166 country codes in
>> the JRE.  So even though the format itself is capable of accepting any (new
>> or old) country codes, it does not work for new ISO-3166 country codes.
> Thats unfortunate.
>  I believe that we should also consider if Currency should implement
>>> Comparable, sorting alphabetically on the currency code. While there
>>> are many possible sort orders, having this as the default one makes a
>>> lot of sense.
>> Having the class Comparable makes sense to me.  Although the default may
>> be arguable (ISO-3166 code has numeric values independent of the three
>> letter codes).
>>  Finally, I'd like to see a method isPsuedoCurrency() added. This would
>>> return a boolean indicating if the currency is 'real' or not.
>> This one is also nice to have.
> I also reckon that a method to get the country codes that the currency is
> valid for would be useful:
> Set<String> getApplicableCountryCodes()
> Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20090824/06f1d699/attachment.html 

More information about the i18n-dev mailing list