Java Web Start Bugs: Offline Edition

Java Web Start is full of bugs that never get resolved and make it next to unusable, and very costly, in business environment. If you have thousands of users who tend to cancel update prompts, or whose connections get interrupted, or who are simply unlucky, you are actually scared of releases. And if you try to release often? Yup, you guessed it.

Rant aside.

Recently I was trying to move away from web-based JWS to one that delivers jars and jnlp to the client and installs locally. I found several interesting bugs or quirks that I think are worth posting here.

Shortcut for all users

My first attempt was installing the application for all users from the Internet. To silently install shortcut on desktop for all users, you can add <shortcut> to your jnlp and execute:


javaws -import -system -silent http://example.com/myapp.jnlp

It does place shortcut on desktop for all users. But it doesn’t work!

Unfortunately, by default Java 6 on my Windows 7 has web start cache in C:\Users\Konrad\.... When you try to launch the app from John’s desktop, you get an ugly error because John cannot access that folder. It doesn’t matter that I run the command with -system switch from Administrator’s console. It lands in user-specific, protected directory.

Workaround: Force JWS to use another, accessible to everyone folder for cache.

Place this in C:\Windows\Sun\Java\Deployment\deployment.config:


deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=false

And in C:\Windows\Sun\Java\Deployment\deployment.properties:


deployment.system.cachedir=C\:\\JavaWebStart
deployment.system.cachedir.locked=true

Offline installation and updates

Specification changed a bit and I researched purely “offline” solution. Place all files in a directory and install from there. Push updates with the same mechanism. In other words, use local file system for codebase and never ask JWS to look online. Official documentation advertises it as “CD installation”.

My JNLP starts with:


<jnlp codebase="file:/c:/myapp/" href="my.jnlp">

Files reside in C:\myapp and I install the app with:


javaws -import -system -silent file:/c:/myapp/my.jnlp

What could possibly go wrong?

Bug 1: You cannot change code if application is running

With web-based JWS, you can update your codebase anytime. Web Start keeps copies of the files in local cache and safely launches the application off that copy. Obviously.

Unfortunately, with local codebase it tries to be smart and does not copy to cache. Now, if you try to update by overwriting contents of C:\myapp while the application is running, it will die with a flood of ClassNotFoundExceptions in log. Oops.

Solution: None, sadly. Don’t update if the application is running. Period.

Bug 2: Curious “do you want to go online” message

OK, so I decided to update only when the application is not running.

Suppose John is running version 3.0.1. He closes the application. Now your smart updater overwrites contents of C:\myapp with 3.0.2. When John launches the application again, he may see a message requesting going online for an update because JNLP has changed.

This will happen if your <shortcut> is set for online="false".

That is plain wrong. My codebase is local, every single thing is local, and the user is bothered with a popup about going online. Then if I accept to “go online”, it innocently informs that it’s downloading update from file:/c:/...

Solution: Use <shortcut online="true">. Then it will always assume the application is “online” and therefore skip asking for permission to go online.

Bug 3: Update reinstalls app and removes shortcut

Remember, I am trying to maintain shortcut for all users at all times.

Now, if you update the application by simply overwriting contents of codebase directory, you’re in for another curiosity. On launch JWS will remove app from system cache and remove shortcuts from all desktops, and reinstall the application into this user’s cache. Others lose the shortcut for good.

Workaround: Reinstall the application into system cache yourself.

  1. javaws -uninstall file:/c:/myapp/my.jnlp
  2. Place new files in C:\myapp
  3. javaws -import -system -silent file:/c:/myapp/my.jnlp

Final rant

Every single time I deal with web start, it bites and makes me weep and gnash my teeth. I spent hours figuring all this out and fighting JWS who fought me back. As I deal with it I find some comfort researching the web and finding other desperate developers coping with similar issues. I hope this post saves someone some pain.

3 thoughts on “Java Web Start Bugs: Offline Edition

  1. Do you know if the option for changing the cache to system level is still valid in Java 7 Update 51? If not how would this be accomplished now?

  2. Paul – I haven’t heard any related complaints from our ops/support guys, so I think these tricks are still working. I’m not 100% sure though, haven’t done this in a while.

Leave a Reply

Your email address will not be published. Required fields are marked *

Spam protection by WP Captcha-Free