Need better Java application deployment strategy

Question

I have various Java Swing applications that are used by multiple users. My deployment strategy is to locate the .jar file on a network share, and users create shortcuts to that file. When the user launches an application, the file is copied to their machine and executed locally. This method allows for a single copy of the code and easy updating.

The problem is that I can't update the file on the network share if any user is using the application at that time.

I can't use Web Start because I don't have access to a cert for signing the jar.

My current workaround is a separate application that copies the desired app to the user's local machine, launches the application, and then the launcher exits. There is a several second delay from when the launcher app exits and the user's app becomes visible.

Can anyone suggest a better deployment method where I can easily update a central copy of the application, one where Windows XP won't maintain a lock on the file?

Update: The JSmooth method solves the essential issues. The .exe created by JSmooth is locked while in use, but the .jar files containing the application's functionality can be updated.

Answer 1

You can use Java Web Start, as you can use a self-signed certificate to sign your files. This will give your users a warning which they can accept once and for all.

I would therefore recommend you going that way, as this is the only standard Java way to do what you want, and it works reasonably well. With the latest Java 6 update you get a lot of new, useful functionality.

A piece of advice: When you release a new version, put the jars in a new location so the URL's pointing to the jar-files inside the JNLP-file change! This is because Java Web Start caches the jar-files and this is the best way we have found to ensure that the cache is accurate.

---

EDIT: I believe you can also use JSmooth to wrap the Java files in an EXE-file, which transparently extracts the various files on the local computer and executes them there. This should not lock the original EXE file. I would, however, recommend you use the Web Start approach.