views:

159

answers:

5

I am wondering if it is possible to have a Java desktop application, on startup, look to some URL, to see if it needs an update, and if so download necessary JAR files, and add them to classpath for the running program.

If the old jars are there, they shouldn't have been loaded into the classloader yet, at this point should they? Is it possible to swap them out before they are loaded w/out restarting the application?

+1  A: 

It's possible but prone to error.

A somewhat cleaner approach is to have a "launcher" application which does not rely on any of the updatable JARs do the above and then launch the actual app.

You may want to check out this question for more details on this topic.

ChssPly76
+11  A: 

JNLP (Java Web Start) will do all of that for you.

Jonathan Feinberg
As a side note, JNLP is more widely known as Java Web Start.
R. Bemrose
Thanks; edited.
Jonathan Feinberg
That is what I normally do. I have an application that would normally be jnlp, but in this particular scenario I am going to launch this application from an already running vm, and start it in the same vm. That part is working. The problem is the application that starts the application that would normally be jnlp is not as easy to update, and it will need some dependent jars in it's classpath to start the other app. Jnlp would solve all of this, but the single vm requirement is the constraint.
broschb
+2  A: 

It should be possible. The URLClassLoader is a place to start.

TofuBeer
A: 

Java Web Start is probably your best bet. The required jar files should be identified in the descriptor allowing your to manage the version control.

If you have a dynamic application that needs to discover and download classes dynamically at runtime, then you could look at Dynamic code downloading using RMI.

crowne
+1  A: 

Java Web Start is a good choice but has some quirks. Notably:

  • Code which is updated must be downloaded before the program starts. A more modern approach would download updates and apply them at next start.
  • Default is inside a sandbox. If you need to go outside of that you must sign your code, which is rather cumbersome until you automate the deployment process (or use Netbeans which helps quite a bit).
  • Problems are not easy to debug - only tool is enabling full trace in the Java Console.
  • Caching of jars in the client is error prone. When you update, be sure that the URL is unique for each deployment component so the cache will not be used.

But WHEN it works it works pretty well. It is to my knowledge the easiest way to have a centralized version easily updateable of a given Java application.

--
EDIT: It appears that the "start program and transparently download updates if available" functionality is present in the latest Java 6. I have not tried it yet, but will soon.

Thorbjørn Ravn Andersen