On Dec 15, Mark Wielaard wrote:
> Hi,
>
> I looked a bit more at how Locales worked since I had never used them.
> And noticed the following things:
>
> The LocalInformation_nl that I send you has a wrong shortDateFromat
> (see diff.1)
>
> java.util.Calendar wants to get the key "firstDayOfWeek", but the classes
> in gnu.java.local define it as "firstDayInWeek". (see diff.2)
>
> The java.lang.String methods toLowerCase() and toUpperCase() can take a
> Locale. But they currently don't use it (but use the methods in Character
> which don't take a Locale).
AFAIK the only locale specific thing is that for turkish local, which
has two different i's one with dot, and one without. For most locales
the unicode uppercase or lowercase is sufficient.
> The getAvailableLocals() method in java.util.Local should be
> getAvailableLocales() (see diff.3) I am also not sure that method
> really does what it should do. But the docuementation is not clear
> on what it should return since it is not clear what "installed
> locales" are.
>
> For the other classes that implement getAvailableLocales() (or actually don't
> implement it) wouldn't it be possible to package the locales in a separate
> jar file and then always load the ResourceBundles through a URLClassLoader
> (which we should then first implement :) using that jar so we can also search
> which classes are available in the jar file?
You are right, we should only return locales for which we have a
localization. But I think we can't use the implementation you
suggest. We must call the getResource on the class loader that loaded
the class, like ResourceBundle does, to support virtual machines that
have their own special class loading mechanism. This means we can't
get a list of resource bundles easily.
I suggest adding an entry to the root resource bundle, listing the
available locales.
> At the moment all 'functionality' for each local is encoded in one big
> gnu.java.locale.LocalInformation ListResourceBundle class. The Hacker's
> Guide says that you should provide a Boolean for every functional area
> that is supported for the Locale (which isn't done/used at this moment btw).
> Wouldn't it be easier if there was a seperate class for all the different
> functional areas? Something like:
>
> gnu.locale.java.text.BreakIterator
> gnu.locale.java.text.Collator
> gnu.locale.java.text.DateFormat
> gnu.locale.java.text.DecimalFormat
> gnu.locale.java.util.Calender
> gnu.locale.java.util.GregorianCalendar
I think it is a good idea to separate them. (I wouldn't separate
Calendar and GregorianCalendar though). Since we need to load only
the classes for which the program requested some local specific
functionality, the overhead should be low enough. I think using
gnu.java.locale.DateFormat should be unique, though.
I will commit your changes soon and look into cleaning up the resource
bundles later.
Jochen
