When Will Java Web Start be Production Quality?
Java Web Start (JWS) has always had great potential. With this deployment platform I can reach users such as mom-and-pops who would otherwise have to call their son (me) when they need to download and install something from the internet. Mom-and-pops are not that interested in computers but they know how to write an email and click a link on a webpage. To start a JWS application all they have to do is click a link on a webpage. While the application is being launched it is also cached locally. It can be started offline and updates are detected and installed automatically. The installation does not require much interaction or even awareness that something is being installed unless:
- JavaSE is missing – in which case it will be installed automatically before the application is launched but dialogs are abundant.
- The application requires permission to do stuff outside the normal security sandbox – in which case a security dialog is shown.
The latter dialog may actually deter mom-and-pops from starting the application but despite this I consider their chances of successfully starting a JWS application to be far greater than that of a native windows application.
A few months ago i revisited JWS but sadly reaffirmed my impression from years back that JWS is not production quality. Many features have been implemented in fashion that I can only describe as “strange”, the documentation is a mess and central features are bug ridden.
Glossing over the release notes for JavaSE 6 update 18 today my eyes caught a number of fixes for JWS. Particularly the fix for a bug I reported myself 6888118: “JNLP Extension Installer is never invoked when uninstalling application“. Uninstalling a JWS application on windows is supposedly simple. The user navigates to the same place in the windows Control Panel where native applications are uninstalled, finds the JWS application and hits “uninstall”. Unfortunately JWS has been broken and would only uninstall some parts of the application – in some cases leaving the user with a system that would complain again and again that the remaining pieces of the application was crashing. Pretty awful bug for such a “mature” system – who dares install this “java stuff” from the net on their PC if it can’t be uninstalled? I hope to test this fix soon.
And oh yea the offline launch of cached applications was broken 6800992. If the webserver was down you couldnt launch the application even though the application was right there on your local system and it was configured to allow offline launch. I built a fairly complicated solution to this problem. I can’t go back to vanilla JNLP if I want to support all those users with a broken version of Java 6.
Another real awful one was this 6863499. The automatic update of jars didn’t work unless your JNLP file that describe the application was simple.
One strange design of JNLP was the requirement of a codebase href inside the JNLP file. Its looks like its now optional for the common case 6866509.
I’m happy that many critical bugs have been addressed but some of them are regression bugs. So with these fixed, what has been broken now? Alright thats a bit pessimistic, I really want to use JWS and I hope update 18 will turn out to have production quality!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)