Updating a JAR whilst running

Question

Given a jar runs within a JVM would it be possible to unload the current running Jar and remove it from the system. Download a new version and rename it with the same name of the last Jar and then initialise the new Jar, creating a seamless update of the Jar within the JVM. Is it even possible to instruct the JVM to perform this action? Is it even possible to update a Jar whilst its running?

Solution 1

Download a new version and rename it with the same name of the last Jar and then initialise the new Jar, creating a seamless update of the Jar within the JVM ... Is it even possible to update a Jar whilst its running?

The JAR file is not 'running', the JVM is running. Your JAR file just contains the class information (aka byte code instructions) that make the JVM do useful work. In most cases the JVM will actually not put a system lock on your JAR file, so you can replace that file to your hearts content.

The real problem of course is that once the JVM loads your JAR it will carry along happily with what it loaded and never read from your JAR file again, no matter how many times you overwrite it. This is the behavior of the default class loader and cannot be changed - however as others have pointed out - you do NOT have to use the default class loader. You can implement your own, similar to what Web Application Servers use, in order to load updated JARS from the filesystem. Caveat though - defining your own classloader is considered a 'Bad Idea™' unless you really know what your doing. You can read more here and here.

Solution 2

This is something that I've seen done many times before (and also done myself). I composed some points of the problems/solutions that might arise.

• JVM will crash with a dump if you overwrite a JAR file that it will use later on.
  • By later I mean classes are loaded quite lazily and some might only be loaded later in your program's life
  • JVM has an open handle for the JAR file and the lib will fail as the JAR and pointers become wrong
  • The probability can be decreased by pre-loading all classes and resources from the JAR file
  • If you have a custom classloader then you can close the handles yourself.
• You will need to know about how class loading is done. Better yet be in control.
  • A custom classloader that will create a classloaders per JAR and manage the versioning
  • Know how your application uses classloaders and how it acts on new JARs (for example check what Tomcat does when you overwrite a WAR archive)
• On Windows your JAR files will be locked and you cannot overwrite them. If you are in control then you can unlock them after use (close them). For 3rd party systems you have to find the respective flags. For example you can check the antiJARLocking in Tomcat context configuration.
• Always better to avoid overwriting the same file and rather have some versioning going on

All in all there are many issues that you might run into when you want to achieve JAR reloading. Luckily there are ways how to minimise the risks. The safest way is to do something similar to get the same effect. Cleanest is custom classloaders and JAR file versioning.

Solution 3

Generally you cannot do this as this behaviour to my knowledge is not officially defined.

You CAN however create a classloader using a jar file outside your official classpath and then load classes from that as you need. By discarding all instances of classes loaded by the classloader you can remove the current resources and then instantiate a new classloader on the new jar file and then load the new classes and create new objects.

This is quite complicated so perhaps you would instead make the jar an OSGi module and invoke your program through an OSGi-loader?

Solution 4

You can't write to a jar that is running. There is no equivalent to getResourceInputStream for writing. I guess that if you try to write using an FileOutputStream, as JVM uses it, you won't be able to delete it as System will prevent it.

Anyhow, it's still possible to offer updates of different modules in different jars. So you could imagine having an application's main jar file that could be updated through a small independant runnable jar file containing the updater.

It's also possible to use JNLP for automatic and seamless updates of an application.

Server side applications are also an alternative to hide updates to user.

Regards, Stéphane

Solution 5

Please pay attention to Tom Hubbard's comment. If a class was not used yet in Runtime (and therefore not loaded), if you remove the class in the new JAR - you will have some issues.

For example, if you will execute the following code:

    public static void main(String[] args) throws InterruptedException {
        long startTime = System.currentTimeMillis();
        while (true) {
            long now = System.currentTimeMillis();
            long delta = (now - startTime);
            System.out.println("Running... delta is " + delta);
            if (TimeUnit.MILLISECONDS.toSeconds(delta) > 30) {
                Me1 m1 = new M1();
                me1.method1(); // ###
            }
            Thread.sleep(1000);
        }
    }

If you put the above in a Jar and execute it, and before 30 seconds will pass, you will change the Jar such that the class "Me1" will not contain "method1" at all (and of course you will remove the line marked with "###"), after 30 seconds of execution you will get an exception:

    Exception in thread "main" java.lang.NoClassDefFoundError: Me1
    at Me.main(Me.java:16)
    Caused by: java.lang.ClassNotFoundException: Me1
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 1 more

View more solutions