Re: [cp-patches] Re: java.util.Currency

[Michael Koch]

Am Mittwoch, 17. November 2004 16:24 schrieb Bryce McKinlay:
> On Nov 17, 2004, at 2:19 AM, Michael Koch wrote:
> > Am Mittwoch, 17. November 2004 02:50 schrieb Bryce McKinlay:
> >> Hi Andrew,
> >>
> >> A while back I was hacking on java.util.Currency and decided to
> >> change our strategy a little. Rather than get the currency data
> >> from the Locales, I've put a separate table containing the data
> >> for each currency into the Currency class itself. This seems to
> >> be the logical thing to do since there isn't a 1:1
> >> correspondence between a locale and a currency anyway. This
> >> should improve getInstance() performance a lot since we no
> >> longer need to go fishing through all locales to find a given
> >> currency code, as well as improving correctness and completeness
> >> for things like
> >> getDefaultFractionDigits().
> >>
> >> I haven't yet tested this extensively, and haven't run your new
> >> mauve tests against it, but perhaps you'd like to take a look at
> >> this code and let me know what you think based on your knowledge
> >> of the Currency class.
> >
> > The relationship between locales and currencies are pretty well
> > maintained by LDML. I don't think we should try to maintain this
> > ourself. E.g. the Euro was introduced 3 years ago and we still
> > don't support it in GNU classpath. With autogenerated data for
> > this from LDML we would give the maintenance burden away to
> > others that do it anyway. We have gnu.currencyen in cp-tools. I
> > haven't tried it yet but guilhem told me it's for this task.
>
> Yes, if the LDML covers what we need then it should definitely be
> auto-generated, but the currency data should be stored separately
> from the Locale data (except that each locale will continue to
> contain the currencySymbol fields, of course, to link
> Locales->Currencies). This way the currencies can be indexed by
> currency code rather than having to iterate through all Locales to
> look up a given code - much more efficient.
>
> It may certainly be a little cleaner to generate a Currency
> resource file, though, rather than putting the table directly in
> Currency.java.
>
> It would be really nice to get all the Locale data sorted out (up
> to date, auto-generated), by the 1.0 timeframe.

My plan is to sort this out in the next 4 weeks.

Currently I'm in contact with some turkish developers (for some 
classpath bug). Testing showed that JDK 1.4.2 does format turkish 
numbers wrong somehow. So we can if we sort this out soon we 
definitely have a bonus.


Michael
-- 
Homepage: http://www.worldforge.org/