Unloading classes passed via RMI

Question

I have a simple RMI 'compute' server application (similar to this) that accepts objects of some interface type from clients over RMI, executes the compute() method of the received object and returns the result over RMI to the remote client. The jobs are 'one-offs' and there is no interaction between the different jobs or between objects of different jobs.

I would like to be able to modify classes and submit instances to the compute server for execution without constantly restarting the server JVM. However when a class that has been modified is submitted again as a parameter to a remote call it's method behaviour does not change (this occurs with anonymous classes also). I have been reading up about serialization and I realise that this is to do with the ClassLoader being unable to modify existing classes.

From my reading on SO and elsewhere I realise that somehow the ClassLoader that loaded the stream class must be GC'd and replaced in order to load a new version of my class. I have an idea how to do this but the situation seems complicated by the underlying RMI runtime and it having its own RMIClassloader.

My question is: What would be the easiest way to load each new version of a class received via RMI parameters. Ideally I'm looking for a way to have each remote call get a new ClassLoader and to dispose of it upon return. Is this feasible to do without an intricate knowledge of customised ClassLoaders and the internals of RMI?

Any pointers to reading materials or examples welcome!

Edit: here is the compute server's remote interface:

public interface ComputationEngine extends Remote {
    public Object execute(Task t) throws RemoteException;
}

and the 'compute job' interface, Task:

public interface Task extends java.io.Serializable {
    public Object compute();
}

Answer 1

This isn't really answering your question, but it might be possible to make changing part of your classes into data instead of the actual class. Use a Map instead of fields, etc. You'd have a lot fewer classes floating around, and your code would probably be simpler too.

Answer 2

The only way to this is to have a new ClassLoader when you want to change a Class. How about making use of the URLClassLoader and making the code available from a URL

I use it in one of my projects to update APIs when the jar file changes. Take a look here: http://code.google.com/p/open-forum/source/browse/trunk/Wiki/org/one/stone/soup/wiki/jar/manager/JarManager.java Line 184+

Check your emails :-)