[EMAIL PROTECTED] 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
_______________________________________________
Classpath mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath
