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

[David M. Lloyd]

On 02/27/2009 03:51 PM, Bob Lee wrote:
> There's no need for insults, David. Have some perspective. I've been 
> nothing but civil and respectful (even after you presumed to know what I 
> do and don't understand).

I haven't insulted you that I am aware of, only stated the facts as I see 
them.  Since you haven't responded to any of my points, I can only assume 
that you do not understand them (which seems unlikely) or you're not 
interested in understanding (which does imply, among other things, a lack 
of respect).  Being ignored in this way gives a distinct impression that 
you're not interested in any solution that did not spring from your own mind.

Allow me to explain another way.  You readily agreed that this problem 
needs a solution (after all, your presentation of your alternative solution 
was the start of the thread).  But you stated flat out that removal should 
not be supported (no justification given); then you basically placed the 
burden on me to justify my position.  Now I have no problem with that; I 
justified myself (more than one time, and quite concisely I thought).  But 
you didn't respond to me at all - instead you circularly argued that my use 
case was invalid; I demonstrated that my use case could not be invalid 
without your use case also being invalid; you ignored me (twice) and 
restated that my use case was not valid without responding to my points.

Does this help you understand my position?

> Non-hierarchical class loaders fall under a) in my book--"code that 
> should probably be redesigned."
> 
> But having used WebSphere in a past life, I realize that's too much to ask.

Not just websphere - any modern application server or container (think OSGi 
for another perspective on the same problem).  This type of problem is also 
quite common with frameworks.  Any application server which provides any 
level of isolation between deployments and libraries can and will give rise 
to a non-hierarchical classloader situation.

> We should probably just wait for ephemerons. I think they alleviate the 
> need for this altogether. With ephemerons, you could have a map of Class 
> -> [some value] where [some value] doesn't prevent Class from being 
> reclaimed. If Class if reclaimed, the reference to [some value] is 
> dropped, too.

I like the notion of ephemerons, but unless I'm mistaken, a notion is all 
they are right now.  I think that we could put in place a solution to this 
problem today, and then migrate the solution to ephemerons later on, if 
they ever become more than ephemeral. :-)

- DML