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

Bob Lee openjdk at crazybob.org
Fri Feb 27 19:15:06 UTC 2009

On Fri, Feb 27, 2009 at 11:04 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> A couple use cases, off the top of my head:
> 1) I've got a set of FooBars that associate with Classes; now for whatever
> reason, I want to change the FooBar that is associated with the Class.  The
> old FooBar is now completely unreferenced; keeping a reference to it is a
> leak.

What's a FooBar? Use cases should be concrete. :-)

> 2) I've got an application server deployment that provides some kind of
> service by class, so I stash refs on the ClassLoaders of the Classes for
> whom the service is provided.  I want to undeploy my application, but all
> those classloaders have strong refs to my deployment.  They all have to be
> cleared or you face a OOM: PermGen after a few redeployments.  In this case
> I'd use a stop() + finalize() on my service which clears them.

Can you provide more detail? It sounds to me like you're saying that
the service impl classes are in the parent class loader and the server
(that binds the services) is in the child class loader, but from my
experience, it's usually the other way around.


More information about the core-libs-dev mailing list