[PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)
openjdk at crazybob.org
Fri Feb 27 21:51:23 UTC 2009
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
On Fri, Feb 27, 2009 at 1:12 PM, David M. Lloyd <david.lloyd at redhat.com>
> I'm not talking about a parent/child relationship at all. I'm talking
> parent, child, AND sibling class loaders. You're presenting a very
> simplistic view here, but in a real application server, things can get a
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev