| d2r diego's weblog |
why we dropped java web startOn 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.devPosted by diego on July 9 2004 at 2:26 PM Comments (please see the comments & trackback policy).
Your post is well-timed; I was about to learn JWS to deploy an app to the masses. I guess I'll have to break out InstallAnywhere. Posted by: Jonathan Feinberg at July 9, 2004 6:06 PMInteresting post. We've casually mentioned trying JWS; it's good to have an idea of what this could entail. Thanks! Posted by: Bob Stine at July 9, 2004 6:07 PMThe way we installed our JWS app is to create an executable using Nullsoft which installs JWS along with the app already cached and does all the custom registry setup transparently to the user, skipping a lot of the problems you have described, when you install it in silent mode there's no user interaction at all, just one-click install. Posted by: inzami at July 9, 2004 6:56 PMA previous employer of mine, a bank, used JWS in exactly the situation you describe 'to quickly deploy point applications within a corporation'. With all the quirks, it probably would have been easier to roll up an MSI and use Microsoft's SMS thingy to roll it out. So while it isn't suitable for widely deployed apps, it's not so hot for internal stuff either Posted by: Koz at July 10, 2004 1:45 AMWe've rolled out a company wide app using JWS, so far we're very happy with it, of course most of your problems seems to be getting JWS installed and the app downloaded. The trick is the initial install, which was done in a fashion smiliar commented by Mr Inzami. Posted by: RefuX at July 10, 2004 2:30 PMHave you looked at the changes made to JWS in JDK 5.0? http://java.sun.com/j2se/1.5.0/docs/guide/javaws/enhancements-1.5.0.html
Thanks for the comments--glad it was a useful post. Inzami and RefuX, you make good points, but: first, the solution you describe is good, but then again it's not JWS is it? You had to spend time and energy into making JWS work in that way, and it should be like that "out of the box". Second, the other problems (API, insulation from native interface, etc), remain. Nadeem: yes, I've seen the changes, and while they are welcome they are nowhere near what is needed. JWS apps still show up in their own "installed" list (only now it's the control panel), they have the same integration problems, and detection of installed environment is still flaky. Posted by: Diego at July 11, 2004 4:15 PMAs for the inital JWS install there is an auto-install link that can be created. I can't see how this is a problem (see http://java.sun.com/j2se/1.4.2/docs/guide/jws/developersguide/launch.html#creating on how to make an auto install link). Yes I agree the splash in front of the dialog is a major problem but this is something that is more JDK related as it has been a problem for a while. One of the major flaws (note I said 'one of') is that it is not consistent with other standards when it comes to warning dialogs and such things. Just load up the plugin preferences and you'll notice that it totally does not fit in with the rest of the desktop when it comes to grammar and basic english syntax. Some points about JWS and deployment: * Complexity On the up side though, with the newer release in Java 5.0, the JWS Application Manager is now only an option with applications becoming integrated with the desktop rather than in the JWS SandBox which I think is a much better alternative - why make JWS apps exclusive to the user? why load one application to start another? Checking to see if JWS is installed should really be a matter of checking to see if the JRE is installed as it's part of this. Sure your coding for multiple browsers but who isn't these days? I'm pretty neutral about JWS and beleive it has it's place in Java App deployment but I still see it in it's infancy. Unless we have a solid user base for it it's not exactly going to bloom overnight. Maybe there is a niche for JWS deployment tools? Surely there must be something out there already that can be used? Anthony Posted by: Anthony at July 11, 2004 11:58 PMOne interface I've seen which I like is the ZeroG web installer. Streamscicle uses it. You can see it in use from here: http://streamsicle.sourceforge.net/installers/install.htm Posted by: Glen Stampoultzis at July 12, 2004 12:30 AMOne interface I've seen which I like is the ZeroG web installer. Streamscicle uses it. You can see it in use from here: http://streamsicle.sourceforge.net/installers/install.htm Posted by: Glen Stampoultzis at July 12, 2004 12:30 AMInitially Java WebStart looked to be quite promising, but while working on it, it created quite many problems. At one particular occassion, the application worked for the first time, but then after that it went into a mode that made it think there is an update at the server, while no update existed - and the application just failed to start. On another occasion it failed to work with some firewall settings or at times it pops up for passwords for an application even when no one wants to connect to the server during startup. diego wrote: > 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.
http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/launch.html#creating We will continue to look into support for other browsers in the next release. > > 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. The problem above was caused by the expiration of the root certificates in the cacerts file. We released update releases of all versions of java before the root cacert expired, containing an updated cacerts file, but this was still a problem for users still using the earlier update releases. >
> 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. If you have more issues regarding java web start, it would be great if you can provide simple testcase and exact steps to reproduce the problem. We would like to investigate into the problem, and if it turns out to be a real bug, we will fix it in a future release of Java Web Start. One good way to submit feedback to us is by the java web start feedback form: http://java.sun.com/docs/forms/javaws-sendusmail.html > 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.
New desktop integration support in 5.0: (1) Shortcut support for applications has been extended to GNOME and enhanced to allow an application's JNLP file to specify where to place the shortcuts. The JNLP file can now suggest desktop and/or start-menu and specify submenu names. You can now put the shortcut in the Startup folder on windows, which does allow launch the application during startup of windows. > Thank you for your interest in Java Web Start. Thomas Ng Copyright © Diego Doval 2002-2007.
|