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

[Bob Lee]

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

On Fri, Feb 27, 2009 at 1:12 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

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

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.

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.

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090227/171bb5ea/attachment.html>