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.
javaws -uninstall file:/c:/myapp/my.jnlp
- Place new files in C:\myapp
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.
Well, I am quiet happy with it…. we use it for client/server applications and works pretty well…
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?
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.