Jochen Hoenicke ([EMAIL PROTECTED]) wrote:
> > 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.
It's not that simple. There are different types of locale specific
functionality, and each one might be supported or unsupported for a
particularly locale.
> > 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.
Yeah, that Boolean thing was just a first thought on how we would test
for whether or not a particular piece of functionality was supported.
Splitting the file might make some sense, but needs to be thought
through. Some of the simple character/rule based behaviors used for
Western locales might not be appropriate for all languages. We'd
need to figure out a way to determine how to support those and how we
detect that they are supported.
--
Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
