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

David M. Lloyd david.lloyd at redhat.com
Fri Feb 27 21:12:46 UTC 2009

On 02/27/2009 02:59 PM, Bob Lee wrote:
> On Fri, Feb 27, 2009 at 12:48 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> I don't think you understood what I wrote
> I understood. I just think you're trying to solve a problem that no
> one really has. 99% of the time, the problem is with a class from a
> parent class loader keeping a strong reference to a class in a child
> class loader.

I'm not talking about a parent/child relationship at all.  I'm talking 
about parent, child, AND sibling class loaders.  You're presenting a very 
simplistic view here, but in a real application server, things can get a 
lot more complex.  A class loader for JAR of an implementation of an API 
might not be visible to anyone else; however the API might be visible from 
several other deployments.  And any deployment who has access to an API can 
pass data to any other deployment.  It's not as simple as you make it out 
to be - there's not just two use cases.

I think what you meant to say is "99% of the time (in Bob Lee's experience, 
and nobody else's experience matters here)..."

You agree that there needs to be a mechanism to store a reference on a 
classloader.  Yet you say that there is no valid use case for removing the 
reference.  I've given you use cases.  You reject them because you don't 
think they're important or common enough.  Yet you do not produce a use 
case which *justifies* the ability to *add* a reference on to the 
classloader, which does not also cause a problem with leakage.

I contend, unequivocally, that there is *no* justification to put a strong 
reference on any classloader but your own which you cannot again remove; 
and if you're going to do that, you should just use a static final field. 
You *must* either demonstrate the utility of such a situation (which, by 
the way, you just stated is no less than 99 times more common of a use case 
than the one I propose), or concede that reference removal is required.  I 
don't see any other logical course.


More information about the core-libs-dev mailing list