Patching Java applications without restarting application

[Serkan Demir]

Hi guys,
Assume that i have an application which needs future patches. Whenever a patch is prepared, i have put this patch into a directory which is pointed in the classpath. The patch will include new versions of existent classes with the same name. The position of this patch is in front of the main application jar in the classpath. So newly created objects will be instantiated from patch without reset application(i am right,aren't i? ). But i am wondering about old objects which is created before patches. If i can customize Classloader, might it be possible to make a runtime patching system which also patches old objects without restarting application ?
Do you know any kind of patching techniques?

thanks lot,

Serkan Demir

[pascal betz]

So newly created objects will be instantiated from patch without reset application

Probably not. The classloader loads the the class definition and then caches it. So it will not reload the class definition (unless you provide your own loader).

might it be possible to make a runtime patching system

Again...probably not (unless you patch the JVM)

pascal

[Paul Clapham]

This can be partially done. The general strategy is this: (1) Have your significant objects loaded by your own classloader (a URLClassLoader would work); (2) When creating a significant object, always create a new classloader to load it (or create a new classloader if the jar file where the classes are located has changed).

You are not likely able to do anything about objects that already exist in your JVM.

[Adam Nace]

Originally posted by Paul Clapham:
You are not likely able to do anything about objects that already exist in your JVM.

Actually, there is a solution to this, too, but it has some definite overhead associated with it. You COULD make a pool of all of your objects of each given class that might be patched (i.e. have the constructor register itself with a collection of Weak References). Furthermore, make all of your classes act through proxies, so that all other objects see is the proxy. Also, provide a copy constructor that is compatable with old versions of the class. Then you can use the collection to obtain a reference to all of the proxies, get the objects contained by them, copy them into new instances of your repaired class, and replace the obect referred to by each proxy with the new version.

Of course, it's easier said then done, and it has a LOT of overhead, but I'm pretty sure it could be done.

- Adam

[Serkan Demir]

I have found this paper.
http://www.cs.purdue.edu/homes/jv/smc/pubs/liang-oopsla98.pdf
There is a good technique explained. A Server class has a Service reference which is highly probable to change. He defined Service as an interface and whenever a patch is needed for Service, he puts the patch into a specific directory and call updateService method.

class Server {
private Servicelnterface service; // use an interface
public void updateService(String location) {
MyClassLoader cl = new MyClassLoader(location);
Class c = cl.loadClass(�Service�);
service = (Servicelnterface)c.newlnstance();
}
public void processRequest (,..) {
service.run(...);

[pascal betz]

the service/server thing could work (i think it's about the same as the proxy solution Adam mentioned). it's easier if the classes which should be swapped are (stateless) services, there are often instantiated in one place and there is no need to transfer state from the old service to the new one. but if you need to swap other objects (e.g. domain objects like "Person", "Schedule" or whatever) because the places where they are instantiated are usualy all over the code base.

another thought: if you have this copy constructor as described in Adams post, then you probably need to apply all the updates in a specific order (from version 1 to version 2 to version 3) because version 3 might depend on state that exists in version 2 but not in version 1 ???

pascal

[Serkan Demir]

you are right Pascal, i think this discussion goes towards a need for a container similar to Spring or EJB.
It is possible to change stateless objects but it is hard to change domain objects. (this remembers me entity and session beans in EJB).
Another question to whom spends time with JMX and manageble objects; I am not familiar with JMX very much but i have known that all objects which implement an interface with a suffix MBean are manageable. Is it possible to inject new objects (but domain stateful domain objects) or change the existent ones via JMX?