how to unload loaded classes

[Petterson Mikael]

Hi,

I have my classes loaded with my own ClassLoader. Now I want to load my
simulated classes ( same package and name). First I have to unload the
previous classes. Shall I use:

System.gc();System.gc();

to unload my classes or is it a batter way?

Cheers,

//mikael

 

[Chris Uppal]

I have my classes loaded with my own ClassLoader. Now I want to load my
simulated classes ( same package and name). First I have to unload the
previous classes.

Classes are unloaded at the discretion of the JVM, subject to (at least) the
following restrictions:

- they will not be unloaded while any instances are still in
existence (have not been GC-ed).

- they will not be unloaded while their owning classloader is still in
instances is still in existence (has not been GC-ed).

- they will not be unloaded while their java.lang.Class object is still
referenced from anywhere (same goes for reflective access to their
members).

So all you can do is ensure that the above conditions are met, and trust that
the classes will be unloaded. You may find that asking the JVM to do a GC will
help, but I can't see much point myself -- after all, if the above conditions
are met, then you don't /care/ whether they've actually been unloaded.

Note that even if they haven't been unloaded, you can still load new versions
of them in a different classloader.

Basically, the unit of reloading is not the class but the classloader.

-- chris

 

[Petterson Mikael]

Petterson Mikael wrote:




Classes are unloaded at the discretion of the JVM, subject to (at least) the
following restrictions:

- they will not be unloaded while any instances are still in
existence (have not been GC-ed).

- they will not be unloaded while their owning classloader is still in
instances is still in existence (has not been GC-ed).

- they will not be unloaded while their java.lang.Class object is still
referenced from anywhere (same goes for reflective access to their
members).

So all you can do is ensure that the above conditions are met, and trust that
the classes will be unloaded.

I only load my classes ( don't create an instance) and do reflection on
them. Does this mean that they will be grabage collected after my
reflection is done?

You may find that asking the JVM to do a GC will

help, but I can't see much point myself -- after all, if the above conditions
are met, then you don't /care/ whether they've actually been unloaded.

Note that even if they haven't been unloaded, you can still load new versions
of them in a different classloader.

So you mean I create a new instance of my ClassLoader then I can load my
my simulated classes?

Basically, the unit of reloading is not the class but the classloader.

-- chris

Thanks for the information.I greatly appreciate it!

cheers,

//mikael

 

[Christian Schlichtherle]

A class definition is actually a tuple of its full package name AND the
class loader which loaded it.

This means you can have multiple versions of classes with the same name as
long as they have been loaded by different class loaders.

Have a look at the class URLClassLoader and Thread. The latter exposes a
method to set the current/active class loader. Sorry can't remember the
method name, but I'm sure you will find it in the Javadoc.

Regards,
Christian

 

[Chris Uppal]

I only load my classes ( don't create an instance) and do reflection on
them. Does this mean that they will be grabage collected after my
reflection is done?

Only if you also release all references to the classloader that loaded them
(and to any other classes loaded via the same classloader). As I said, the
unit of unloading is the classloader, not the class.

So you mean I create a new instance of my ClassLoader then I can load my
my simulated classes?

Yup.

BTW, Christian (in a different post in this thread) mentioned
java.lang.Thread.setContextClassLoader(). As far as I know, that's not
relevant for your purposes here. Indeed, I've never found out what purposes it
is /supposed/ to be relevant to -- the documentation is non-existent and
(again, AFAIK) that data isn't even used in the places where you'd hope that it
would be, such as de-serializing objects of classes that are only known to
custom classloaders. If anyone has more information/pointers about the
"context" classloader then I'd like to see it.

-- chris