On 02/27/2009 02:59 PM, Bob Lee wrote:
On Fri, Feb 27, 2009 at 12:48 PM, David M. Lloyd <david.ll...@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.
- DML
