Re: Locale ResourceBundles

[Bryce McKinlay]

David Holmes wrote:

> 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?
>  

Good question. As you point out, getSystemClassLoader() will give the 
application classloader, so if we use the result of 
getSystemClassLoader(), then resources could be loaded from the 
application classpath instead of just the bootstrap classpath (ie 
glibj.jar). Which one we want depends on whether users/applications 
should be able to add their own locale data independently of 
Classpath's. I'm not sure whether that would be a useful feature, but 
I'm going on the assumption that its not really a _bad_ thing. Any opinions?

> > 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.
>  

Yes, but the getSystemClassLoader() call only needs to be made once. 
After that, the ClassLoader can be stored in a private field and reused 
for subsequent getBundle() calls.

> > 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. 

The missing link here is the Locale->ResourceBundle association. The 
Locale class is just an identifier, it doesn't have any API to actually 
load/examine the Locale information. This is left up to the classes that 
actually need the locale data to implement.

Calendar could certainly maintain its own cache of Locale->bundle 
mappings, thus bypassing the classloader stuff, but I think that a) 
having too many levels of caching becomes counter-productive - 
ResourceBundle already has a perfectly good cache, and b) the problem is 
not just in Calendar: every class that wants to load Locale data would 
need its own cache.

> 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

I don't think we're short-circuiting any security checks here. All we're 
doing is passing a ClassLoader explicitly to getBundle() instead of 
forcing it to look on the stack to determine which classloader to use.

Regards

Bryce