Re: Patch: FYI: java.text merge

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:

Anthony> This shows a different bug.  These LocaleInformation classes
Anthony> look like they're written to be combined somehow
Anthony> (LocaleInformation_en_US only covers what's not in
Anthony> LocaleInformation_en).  I suspect that this isn't happening
Anthony> properly.

Ok, yeah.  It happens properly if the locale is en_US, because of how
ResourceBundle looks up the parents.  But when found as the default
locale the chaining won't happen.

It isn't actually clear to me that the current behavior is wrong.

    Locale.setDefault (new Locale ("ie", "ee"));
    DateFormatSymbols dfs = new DateFormatSymbols ();

Your program sets the default Locale.  The no-arg DateFormatSymbols
constructor is defined to throw MissingResourceException if the
resources for the default locale can't be found.

Now, if you did `new DateFormatSymbols (new Locale ("ie", "ee"))', and
didn't change the default locale, then I'd expect things to work...

... except that on my machine, at least, libgcj thinks the default
locale is `en' and not `en_US', which leads to problems.  (I have a
fix for this which I'll test shortly.)

It isn't clear to me what, if anything, we can do here.  It seems to
me that we can't meaningfully put certain information into the basic
`en' locale.  For instance, it doesn't make sense to put monetary
formatting info there.

Long term of course the best solution is to write our own locale
compiler and generate all the locale information.

Tom