Class loaders no longer used can be garbage collected (unless there is a memory leak, as is often the case with using ThreadLocal, JDBC drivers, java.beans, etc).

If you want to keep the object data, then I suggest a persistence mechanism such as Serialisation, or whatever you are used to.

Of course debugging systems can do fancier things, but are more hacky and less reliable.

It is possible to add new classes into a class loader. For instance, using URLClassLoader.addURL. However, if a class fails to load (because, say, you haven't added it), then it will never load in that class loader instance.

if my initial classloader loaded stuff like threadpools and other resources, does it not mean that the new classes loaded by the second classloader will not be accessible to those resources?
–
Amir AradOct 11 '08 at 22:02

I've not specified a parent for the URLClassLoader so it'll just use system (I'll fix). That will mean it'll still be able to access classes on the classpath. If you want to share stuff, pass references around using types defined in common class loaders (perhaps the boot class loader for Java lib).
–
Tom Hawtin - tacklineOct 11 '08 at 22:29

I was asked to build a java system that will have the ability to load new code while running

You might want to base your system on OSGi (or at least take a lot at it), which was made for exactly this situation.

Messing with classloaders is really tricky business, mostly because of how class visibility works, and you do not want to run into hard-to-debug problems later on. For example, Class.forName(), which is widely used in many libraries does not work too well on a fragmented classloader space.

The jar URL is for pointing at a resource with a jar file. You want to pass the whole jar file over to URLClassLoader. (Unfortunately jars within jars is broken.)
–
Tom Hawtin - tacklineOct 11 '08 at 21:58