Now blogging at diego's weblog. See you over there!

why we dropped java web start


On a question in the clevercactus forums, John was asking why we stopped using Java Web Start to distribute share (and in fact other applications). We started using JWS late last year to simplify deployment and updates. Making sure that the updates in particular didn't require a reinstall was critical for us, since we usually spin out new version fairly quickly during betas, so JWS was good in that sense. As soon as we released the "internal" beta of share, it became obvious that JWS was a huge problem for most users. We want share to be easy to use, and that includes easy to install (and, yes, uninstall if necessary) and JWS was getting in the way in more ways than one. Here's why.

Problem one was installation: we had to detect whether people had JWS installed or not, and the procedure for detecting this is quite simply a joke. You need to code for multiple browsers and in some cases it isn't guaranteed to work.

Now, if you didn't have JWS (and skipping over the problem of detection) you had to install the virtual machine yourself, usually by being redirected to the java.com site. The site, while no doubt a good showcase for the Java brand, is terribly confusing to a user that only wants to install share, and not Java, and most have no idea of what Java is, and, more importantly, they shouldn't care.

Now let's skip over the problem of java.com being utterly confusing (you'll note we're going to be doing a lot of "skipping over" in this discussion) and say we hosted the JVM ourselves for download to simplify the process, users still had to install a separate piece of software, and one that installs all sorts of icons in your desktop and programs folder, which again terribly confuse non-technical users.

So let's skip over all of that (see what I meant before?), and say that the detection does work, and JWS is installed, the user is often presented with a dialog asking to run a file of type "JNLP" which makes little sense. Now say that you ignore that and click "OK". The app runs. You are presented with a horrible warning dialog with an unfamiliar look and feel (the Metal L&F, why Sun doesn't use the native L&F for this is beyond me) that for someone who's never seen one sounds like you are about to give permission to something to do all sorts of evil things on your PC, create havoc and possibly come in to your house at night while you're sleeping and steal all your furniture.

The point is not that the security warning is wrong, since it is accurate, but users are put off by it. They already know that they are downloading an application, and they do so everyday for other things, and native applications have as much ability (in theory) to do Bad Things as a JWS app with full privileges. The warning is confusing because it seems to be something extra that they're giving permission for. (Incidentally, I don't fault JWS on this point, users should be warned, the problem is that the warning is completely different from other warnings they might see when downloading applications as they usually do).

Much worse than this was when users ran into the invalid Java certificate problem, which didn't allow them to install the application at all even if they wanted to.

But let's say that they accept the certificate (yes, the skipping over again). The app runs. Bing! Window locked. Why? Because JWS is asking you to create shortcuts to the app. It was very easy to get confused because the dialog for this was modal, and sometimes it would end up behind the splash screen or the app, which left most users confused. (Yes, this bug has probably been fixed in the latest JREs, but how many broken JREs are out there?).

All of this, and I haven't even mentioned the problems that occur when you, say, switch download locations for the JARs, for example, if you need to deploy on a server with more bandwidth. Or the problems that come from detecting that JWS exists but that it's an incompatible version (and you can't tell). Or the problems that exist when JWS has cached the old JNLP file and doesn't want to let go. Or the fact that you've only got limited resources and it's impossible to test against all the JREs that are out there. Or... well, you get the idea.

As a development environment, JWS has significant shortcomings as well, since it completely insulates you from the native platform, which is good, but it gives you almost no way to access the native environment, which is a disaster. Simple platform-integration things, like launch-on-startup, or right-click integration, become nearly impossible. Btw, this isn't getting better in the next release, as Erik noted recently. Aside from cosmetic changes and a few new features (like the ability to make changes to the launcher UI) Java 5.0 is pretty much the same in terms of JWS and other platform integration features.

I think that JWS has its place in tightly controlled environments, for example, to quickly deploy point applications within a corporation, where the target machines are well known (in terms of software installed), the infrastructure is small, etc. In those situations, JWS is an excellent way of quickly an easily deploying your app to users and not having to deal with creating installers and such.

But for end-user applications that have to be easy to use and install and widely deployed, JWS, in my experience, doesn't quite cut it---and even though we put a lot of effort into making it work, that's why we had to stop using it.

Categories: soft.dev
Posted by diego on July 9 2004 at 2:26 PM

Copyright © Diego Doval 2002-2011.
Powered by
Movable Type 4.37