A small ClassLoader change proposal
ekabanov at gmail.com
Thu Sep 16 14:06:56 UTC 2010
Yep, ephemerons would be great, but they failed to materialize so far and need support from the GC AFAIK. Whereas this is just one field in the ClassLoader which solves very real problems in a lot of use cases. The truth is that class loaders are leaking in most of the user applications I had access to and having a WeakClassLoaderReference would help a great deal to write libraries that don't leak them. And if the ClassLoaderLocal seems complicating, there's no real need to expose it, as the new reference type is what is needed most. Also, unlike ephemerons, this is backportable.
On 16.09.2010, at 16:53, David M. Lloyd wrote:
> This comes up from time to time. I proposed a very similar thing a while ago and was shot down ("wait for ephemeron support!").
> On Sep 16, 2010, at 8:44 AM, Jevgeni Kabanov wrote:
>> On 16.09.2010, at 16:33, Rémi Forax wrote:
>>> So you want to create a classloader local like there is a thread local.
>>> You can subclass ClassLoader and put your field in the newly created class.
>>> Why do you need to put your localMap in java.lang.Classloader ?
>> Because I want it to work with any class loader, not just the ones created by me. In a typical Java EE app you have a lot of custom class loaders created by the container, frameworks and the app. I want to be able to hold a reference to an object, without having to think about what happens when that app is redeployed.
> - DML
Jevgeni Kabanov: Founder & CTO at ZeroTurnaround
jevgeni at zeroturnaround.com | Skype: ekabanov | http://twitter.com/ekabanov
"first and only jetty context reload of the day (java inheritance change). Love #JRebel" - Ivar Abrahamsen
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev