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