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

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

More information about the core-libs-dev mailing list