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:
- You launch a Java application (the launch app). This application takes a single parameter which is a URL of a JNLP file.
- 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.
- 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)
- 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:
- Visibility, you can log exactly what is happening
- 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.
- 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