[PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)
David M. Lloyd
david.lloyd at redhat.com
Fri Feb 27 22:32:05 UTC 2009
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. :-)
More information about the core-libs-dev