How to start an external jar in the same JVM and still be able to terminate current main()

Question

I'm particularly new to Java, therefore my question could be total BS, but I am faced with the challange of creating an Updater Wrapper (java app) to an existing Java Application, of which I cannot get my head wrapped around.. The issue I'm facing is, that we don't want to spin up a second and a third JVM each time we have to start a new jar, but Step 5)'s termination is blocked by the Thread of the Updater, which was started from Classloader of the Updater.jar.

Concept:

1. Current version of App gets triggered to check for updates
2. Starts Updater.jar
3. OnUpdateAvailable -> closes incoming connections and saves application state and its objects
4. Sends ReadyForUpdate Signal to Updater on socket
5. Current application terminates.
6. Updater replaces Application executable and resources
7. Updater launches New Version of Application.jar with argument to resume to its previous state
8. Updater waits for Application -> to initialize successfully
9. Updater terminates
10. New version of Application is up and running

Question: Is there a way to use the same Virtual Machine to start first the updater and then the new version of the application from the updater or should we go ahead with the separate JVMs?

java version: 1.7.0_05-icedtea OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)

Answer 1

I think that it would be far simpler to do this with a separate virtual machine and a wrapper script.

Your problem at step 5 is that it requires the application to "shut down" without calling System.exit and without running the shutdown hooks:

• This could require major re-engineering of your application code-base.

• Even after you've done that, you still have the problem that old application state is likely to "linger" via objects loaded using the old classloader. Getting rid of that could be really difficult. And if you don't then:

  • you've got a permgen leakage,
  • you may have a non-permgen memory leaks (e.g. via statics in classes that have been replaced), and
  • you may have leakage of application state that could cause problems for the "relaunched" application.