Webstart is a nice solution for deploying Java applications. But when it comes to a corporate environment, it has a not-so-small problem: The Java Runtime System itself.
If several applications share the same Runtime, you may get into version trouble—Some applications want to have the latest Java version to fix some bugs. Other applications don’t want to update because they fear incompatibilities. Or there is simply no budget for regression testing all applications with a new Java version.
Some of you may argue against it because Java has claimed to be always backward compatible—But believe me, that’s not true. I took part in three version updates 1.3=>1.4=>1.6 and there were always changes in the behavior of the UI that need to be addressed!
In my opinion, an optimal Java (standalone) application is simply copied into a local directory and has its own Java Runtime inside this directory. That way, it can be easily removed by simply deleting the directory, and it no side effects occur with different JRE versions or with the OS environment in which it’s running.
But how do we update such an installation? We simply use Webstart as a kind of Bootstrap Loader!
The process should be as follows:
- Start a generic updater with Webstart.
- The updater refreshes all changed JAR files of your application. This includes the JRE itself that lives inside the application directory.
- Finally, the updater starts your application using the local Java Runtime.
That way you have best of both worlds: The updater itself is updated with the standard Webstart mechanism, and your application runs completely independent from the environment. A nice surplus is that you no longer need to sign your JAR files because the main program is no longer a Webstart application (only the Generic Updater needs to be signed).
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}