RE: Locale ResourceBundles

[David Holmes]

Bryce,

> However, getting the classloader argument for getBundle() can be a
> problem. Currently we use the system classloader as returned by
> getSystemClassLoader() (using something like
> Calendar.class.getClassLoader() unfortunately doesn't work because that
> may return "null" for the system classloader, and null is not a valid
> argument for getBundle() ).

I'm a little confused by your terminology here, the "system class loader" as
returned by ClassLoader.getSystemClassLoader and as implemented by
VMClassloader.getSystemClassLoader is the *application* class loader  ie
that loader used to load the class whose main method you want to execute.
This classloader should never be null.

In contrast, the bootstrap classloader, which is used to load the "system
classes" (those logically in the 'bootstrap classpath'), such a Object,
Class, Calendar etc, may be null. If you do Calendar.class.getClassloader
you are asking for the bootstrap loader not the "system loader".

So which classloader do you actually want?

> But, getSystemClassLoader is a privileged
> call and requires an AccessController.doPrivileged() to call safely in a
> secure environment.

It requires a security manager check involving the calling classloader -
which is the same overhead that you were trying to avoid by using the
getBundle form that takes a classloader - at least when a security manager
is installed.

> Rather than having to add an AccessController.doPrivilaged() to every
> getBundle() call in every class that uses Locale data, I wondered if we
> can use a "LocaleHelper" class to cache the system classloader and
> simplify locale bundle lookups from the classes that need access to them.
>
> My question is - could the LocaleHelper class be a security problem?

I'm confused as to who as is asking for what here and which code you are
trying to optimise - my apologies if my lack of understanding has made me
miss the point.

I would expect caching to be performed at each level. If the calendar
requires locale information and the locale requires a resource bundle, then
I would expect Calendar to cache the locale, and locale to cache the
resource bundle, and resource bundle to actually cache the resources. Any
necessary security checks when acquiring the initial values would be
performed as defined/required, but should only happen once per
calender/locale combination. Short-circuiting the security checks would seem
to me to be presuming what security checks needs to be made, and while it
might seem harmless, to me it seems the wrong thing to do. But as I said I'm
not clear exactly what code you are planning on changing to use the cached
application class loader.

Cheers,
David Holmes