[PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)
David M. Lloyd
david.lloyd at redhat.com
Fri Feb 27 20:48:08 UTC 2009
On 02/27/2009 02:18 PM, Bob Lee wrote:
> On Fri, Feb 27, 2009 at 11:44 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> WeakHashMap<Class<?>, Externalizer>()
>> *fails* because Externalizer instances are usually customized to the class
>> they externalize (which, by the way, could well be a system class). This
>> means that Externalizer keeps a strong ref to the Class after all.
> If the class is from a parent class loader, you should just keep a
> strong reference to the data and not use
I don't think you understood what I wrote - keeping a strong reference to
the data defeats the purpose of the mechanism utterly. I'll try to lay it
out a little more plainly -
1) I need to associate some data with classes - which can come from
anywhere, any class loader. This is not an uncommon requirement. Anyone
who has ever written a Map<Class<?>, ?> has realized this requirement.
2) The data may have a strong ref to the class it is associated with. This
is a consequence of the purpose of associating data with a class key.
3) The module responsible for establishing the mapping must not maintain a
strong reference to the class, to allow that classloader to be collected.
4) The module responsible for establishing the mapping must not maintain a
strong reference to the data, to allow the deployment which created the
data to be collected.
5) The mapping must remain until a collection of (3) or (4) occurs, or else
the purpose of caching data per-class has been defeated.
These rules would apply for *ANY* case where one might want to maintain a
Map<Class<?>, ?> of any sort. Your solution allows the map, but does not
allow the value to be changed or removed - EVER - and if the map is
collected, all the values would still hang around.
My solution fits the use cases I've provided. I don't understand how it
could possibly be OK to *ever* put a permanent reference on to any
classloader but your own, without a way to clean it up. And if you're
going to do that, just use a static final field. I just don't see the use
case that would benefit from such an ability.
More information about the core-libs-dev