<i18n dev> Currency updates in JDK 7

[Stephen Colebourne-2]

I've been reviewing the Javadoc for the JDK 7 Currency class changes
(bug 6332666).
http://download.java.net/jdk7/docs/api/java/util/Currency.html

The updates appear to allow users the ability to override the built in
currency data, as indicated in the class javadoc:

"Users can supersede the Java runtime currency data by creating a
properties file named <JAVA_HOME>/lib/currency.properties. The
contents of the properties file are key/value pairs of the ISO 3166
country codes and the ISO 4217 currency data respectively. The value
part consists of three ISO 4217 values of a currency, i.e., an
alphabetic code, a numeric code, and a minor unit. Those three ISO
4217 values are separated by commas. The lines which start with '#'s
are considered comment lines. For example,

#Sample currency properties
JP=JPZ,999,0

will supersede the currency data for Japan. "

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.

Further, the Javadoc is unclear as to whether users can _add_ new
currencies. An example would be if a country split, like Czech/Slovak,
and created two currencies. Does the new format add a currency to the
built in list if it isn't recognised?

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.

Finally, I'd like to see a method isPsuedoCurrency() added. This would
return a boolean indicating if the currency is 'real' or not.

Otherwise the changes pretty much complete the use cases for the class.

Stephen

[Naoto Sato]

Hi Stephen,

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.

>
> Further, the Javadoc is unclear as to whether users can _add_ new
> currencies. An example would be if a country split, like Czech/Slovak,
> and created two currencies. Does the new format add a currency to the
> built in list if it isn't recognised?

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.

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

Naoto

>
> Otherwise the changes pretty much complete the use cases for the class.
>
> Stephen

[Stephen Colebourne-2]

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:
EUR,978,2,IEFRESPTFIBENLLUDEATITMTSKSIGRCYADMCMESMVA
FJD,242,2,FJ
FKP,238,2,FK
GBP,826,2,GBIMJEGGGSIO
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

[Mark Davis ☕]

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 info.

See:
http://unicode.org/cldr/data/common/supplemental/supplementalData.xml

<currencyData>
  <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"/>
</region>

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

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

Mark

On Mon, Aug 24, 2009 at 13:53, Stephen Colebourne <scolebourne@...> 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:
EUR,978,2,IEFRESPTFIBENLLUDEATITMTSKSIGRCYADMCMESMVA
FJD,242,2,FJ
FKP,238,2,FK
GBP,826,2,GBIMJEGGGSIO
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