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

[Kevin Bourrillion]

This thread needs a third perspective (which I can't provide for lack of
expertise).



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

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



-- 
Kevin Bourrillion @ Google
internal:  http://go/javalibraries
google-collections.googlecode.com
google-guice.googlecode.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090227/e6d92e36/attachment.html>