Re: ResourceBundle optimisation

[Bryce McKinlay]

address@hidden wrote:

> While you are at it...
>
> I remember a discussion ( somewhere, somewhen long ago) about a probable
> bug with ResourceBundles, that they stay in memory (because of caching) 
> and that they should be dropped from cache somehow.
> Maybe its a good idea to use one of the WeakReference-things to drop it
> when no longer needed.
>  

Yes, I think this a valid problem with the current implementation. 
Currently getBundle() keeps hard references to all the ClassLoaders that 
it is called from, meaning that none of those ClassLoaders (and hence 
the Classes and Resources that they load) can ever be garbage collected.

This is solvable, however, by spitting the bundleCache into a two-level 
hashtable - the first being a WeakHashMap with the ClassLoaders as the 
keys. This way, when a ClassLoader becomes otherwise unreachable, it 
will be eligible for collection along with all the bundles it loaded.

> Another idea: invent a System.property to control cache-behaviour.
> With a useful default, users can tune as they like: 
> cache, no cache, cache forever, cache with expiration...
>  

In general, I dislike adding additional, non-standard system properties. 
They create new code paths that will rarely get exercised, meaning 
additional testing & maintenance work. Meanwhile, users rarely bother to 
set them to anything other than the default. In a few cases, it might be 
worthwhile to add one, but I suspect not here.

Bryce