Michael Schnell is living in Hamburg (Germany) and works as a Project Manager, Architect and Senior Java Developer. Michael is a DZone MVB and is not an employee of DZone and has posted 13 posts at DZone. You can read more from them at their website. View Full User Profile

A Better Java Webstart for Standalone Apps

03.03.2011
| 8414 views |
  • submit to reddit

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:

  1. Start a generic updater with Webstart.
  2. The updater refreshes all changed JAR files of your application. This includes the JRE itself that lives inside the application directory.
  3. 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).

Published at DZone with permission of Michael Schnell, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Boaz Lev replied on Thu, 2011/03/03 - 3:05am

How you implements such a solution? what should be the jnlp configuration?

Gervais Blaise replied on Thu, 2011/03/03 - 3:21am

Yes you're right, But WebStart don't serve anything in your case (he just update the updater..). You can write your own updater/launcher who check an app descriptor and maybe update your app before really launching it.

Eugene Shkel' replied on Thu, 2011/03/03 - 4:07am

What about using full version of java in jnlp file? 

<java version="1.6_22"  />

 It's a little buggy now, but I hope it will be fixed in nearest time.

Alan O'Leary replied on Thu, 2011/03/03 - 5:53am

This post should really show some level of detail in steps 2 & 3 to be of any value.

- How do you package the webstart app so your code does not have to be signed

- How do you "script" the application so that webstart can kick off some actions 

- etc..

Christian Kulen... replied on Thu, 2011/03/03 - 6:14am

You have to sign the webstart jar (for the updater). The updater downloads new (unsigned) JARs i.e. via HTTP and puts the JARs into the Standalone-Application-Folder. The updater may communicate with the standalone app via sockets?! You can launch the standalone app with Runtime.exec.

Jon Strayer replied on Thu, 2011/03/03 - 11:28am

"The updater may communicate with the standalone app via sockets?"

I did that with an application once.  Clicking on the webstart link would install the application if it wasn't installed, start the application if it wasn't running or trigger an event if it was.  

 

I think Eugene's solution is best.

 

 

Michael Schnell replied on Fri, 2011/03/04 - 5:27am in response to: Boaz Lev

> How you implements such a solution? what should be the jnlp configuration?

Here is an example what files are necessary in a Generic JNLP: kickstart4j.jnlp

Michael Schnell replied on Fri, 2011/03/04 - 5:29am in response to: Alan O'Leary

>This post should really show some level of detail in steps 2 & 3 to be of any value.

Here is a live example you can try.

Kirk Hill replied on Sun, 2011/03/06 - 9:56am

Our company is currently using webstart now using a JRE that is installed with a custom installer just so we can make sure that our app is using a specific version of the JRE, but this means we have to maintain a seperate custom installer which is written in .NET. I am thinking of switching us over to a simple webstart bootstrapper which simply starts up an osgi container via an embedded JRE and this OSGi container will have bootstrap code for getting its bundles via straight HTTP calls. Has anyone else taken a similar approach?

Michael Schnell replied on Sun, 2011/03/06 - 11:21am in response to: Kirk Hill

Something very similar is already supported by Kickstart4J - You can use a kind of Lazy Loading to retrieve the necessary JAR files on demand and add them programmatically to the classpath:

// Path relative to the installation directory 
// and file to load
File jar = fileLoader.loadFile("lib", "abc.jar");

// Add the JAR dynamically to the classpath
Utils4J.addToClasspath(jar.toURI().toURL());

The only difference is that it's not OSGI based, but this should be easy to add. Instead of adding the JAR to the classpath you would load it as an OSGI bundle.

Tire Works replied on Thu, 2011/08/04 - 9:42am

Java software applications can be deployed with a single click over the network using Java Web Start technology. -Tire Works

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.