Alternatives to Java Web Start? [closed]

Question

We're having huge issues with Java Web Start in production. We're afraid to release because every time we do, help desk gets calls from 1/3 users getting an "unable to launch" error. It's hard to tell whether it's because of user error, cancellation in the middle of download, poor network connection or anything. But the bottom line is:

We find it terribly unreliable.

What are the alternatives for deploying and updating a rich Swing application? Either free or commercial, I'm more interested in features and robustness.

Reliability is key, but I would also like to have the following:

• Install once, update automatically from a simple HTTP hosting like JWS
• Differential updates
• Support for multiple configurations (think of 30 instances which may have different versions of the application or different launch parameters - would be nice not to build 30 artifacts each time)
• Win / Mac / Linux support. Hopefully one that does not mean I have to maintain 3 builds for each instance.

Answer 1

I feel your pain, the biggest issue I've had with JWS is visibility, that is, what is it doing and why is it doing it. Most of our issues were related to internal proxies (Java seems to really not like authenticating proxies) and the wrinkles seem to be ironed out for the moment. Nevertheless, I did consider simply writing a replacement. This is not as crazy as it sounds, JWS does an awful lot of stuff that I don't really care about, namely, integrating with the web browser and checking JVM versions. Consider the following scenario:

1. You launch a Java application (the launch app). This application takes a single parameter which is a URL of a JNLP file.
2. The launch app hashes the URL and uses this as the basis for a local folder (repository) in which to store any downloaded jars for the app. If the repository doesn't exist, it will create it.
3. The launch app attempts to download the JNLP pointed to by the URL. If it can't download it, it will just launch whatever is in the repository (maybe warning the user)
4. If it can download the JNLP, parse it and list any jars that need downloading. If you already have the jars, use something like Apache HttpClient in order to determine whether the server has a newer version and download if required. The important point is that any downloads should be stored in a temporary folder. Once ALL of the downloads have succeeded, you can apply these to the local repository. Ideally, you will back up what is already there in order to allow some sort of rollback procedure.

This should provide some very significant advantages over regular JNLP:

1. Visibility, you can log exactly what is happening
2. Much better failure modes: if the download gets interrupted just launch the version that's already there (obviously, this won't work if the interrption occurs on the first download), if you feel like telling the user about it then do so.
3. By running as a local app you should avoid running into issues with signing of jars, I honestly don't understand the Java Web Start security model with respect to signed jars but it seems that if different classloaders are involved, JWS will complain about it (I think)

Sadly, I'm not in a position to fire you over a working version of the above, I did start a prototype but suspended it. I may have to return to it in future in which case, I'll be happy to share the finished version.

Cheers, Phil

Answer 2

Currently we are using GetDown to handle distribution of our swing applications. We use Tomcat to distribute updates and GetDown to download those updates. It's really flexible and powerful, and much better than java WebStart and because it produces check sum for changes it saves bandwith and downloads just changed files.

A good tutorial : http://www.hascode.com/2012/05/creating-updatable-java-applications-using-getdown-and-the-getdown-maven-plugin/