[PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

[David M. Lloyd]

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
> ClassLoader.keepReferenceTo().

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.

- DML