Remember that the use cases for JWS apps are fairly unique. It’s solving a relatively unexplored problem: auto-updating, web-based delivery of flexibly sandboxed applications that run outside the browser, integrated with the native desktop. Think about what the technology is trying to solve: if that use case doesn’t match yours, then go with a native installer. Personally, I think the sandboxing support (i.e. safe like an applet) but running outside the browser (i.e. not burdened with the web’s navigation metaphors — e.g. pages, refresh, round-trips) are worth the pain.

Remember, if you use native installers, your users have to trust you 100% not to do naughty things in your code. And if your site is hacked, and your native installers violated, that’s quite different than if someone were to replace your JNLP and java code. With the JNLP solution, the users would at least be warned the code wanted to do something naughty but was unsigned. With the native installer … ! That’s a potential liability issue.

Last but not least, Java is (somewhat) open now — why not go fix the problems you see and contribute them to Mustang? You’ve been enjoying Java technology for free, why not give something back? ;-)

2. Users don’t like the experience:
I strongly disagree! Most of the people I know despise applets, they make the browser hang while loading Java for the first time, they cause the entire browser to crash when they fail and in order to have any decent functionality they need a modern VM installed (so no advantage there).
Most of the people to whom I showed webstart LOVED the experience and were very surprised at how smooth it is. I just send out a link to the website with no instructions and technical people figure it out very easily, less technical people manage with a little help (or a better web site).

3. Java/JWS detection in the browser is necessary, and unreliable:
Yes, but thats a browser problem and NOT JWS’s fault…
Technically our website only supports modern browsers (mostly for CSS reasons) and so these browsers work better with the detection. Although IE was a pain because that piece of crap refused to detect JWS when I moved the code to a script file (Firefox worked great with the external script).

4. Users don’t know what JNLP files are:
Agreed. But they don’t know what MSI, class, jar or many other types are… In Windows the default behavior is to hide the extension. Most users wouldn’t care since they just click here and once they get used to it they will know… Its a chicken and egg thing if JWS is ever successful.

5. You cannot make the user experience much better:
True, there is a limit to what you can do. However, if you will try the latest Mustang builds you will see that the user experience is much improved with 0 work on your part. Thats the advantage of using a standard deployment tool.

6. The only reasonable solution is native launchers:
It all depends on the use case. Native launchers will force you to deal with multiple versions and forcing users to upgrade manually. Everything has a price… However, JWS has a nice idea which you failed to mention the JDIC packager: https://jdic.dev.java.net/documentation/packager/example.html which takes a JNLP application and produces a NATIVE MSI installer or RPM package. This installer will then autoupdate over the network just like a standard JNLP application.

Don’t get me wrong, I understand EXACTLY what you are ranting about and I can’t say its unjustified. I just think you will be back with JWS when you try to use a different tool for something thats very appropriate to JWS.

Keith Lea pointed out that he will never deploy with Java Web Start again.
With Web Start in its current form, he’s be deploying with it longer before I will use it again. “Never” is much too soon.. here is why, echoing and expanding…