Why I will never deploy with Java Web Start again
I used JWS for a popular application called RPI Scheduler. It allows Rensselaer Polytechnic Institute students to plan their schedule for the next semester, based on the school’s course data. Thousands of students use it every semester.
I regret using Java Web Start for this project. It is not extensible, reliable, or user-friendly enough to support even my small application used by mostly computer nerds.
Java Web Start doesn’t work for a large number of users
Every semester I get about 10 posts to the program’s message board by people who can’t run the scheduler. I usually go through the process of looking through error logs and clearing caches and usually it doesn’t work, and these people simply cannot run the scheduler. These people all have the latest version of Java installed.
I imagine that most people who can’t get it working don’t post to the message board. Even if 1 in 4 post to the message board, that’s 40 out of a few thousand students, around 1-2%, who can’t run the scheduler at all.
Users don’t like the experience
Long ago, the scheduler used to be an applet. I get feedback from people saying they liked it better as an applet. I guess it’s for the same reasons that people like webmail: there’s zero setup, zero configuration, very short wait before it launches.
Java/JWS detection in the browser is necessary, and unreliable
To provide a good user experience you need to detect JWS and Java in the browser, so you can ask the user to download Java if they need to. There’s not an easy way to detect reliably from the browser. I use a hacky VBScript+Javascript combination from a Sun tutorial, which worked with some modifications. It only works well on Windows with IE. I had to make a page saying “If you think you have Java installed, click here” and so on, which a large percentage of users see (including all Linux and Mac users).
Users don’t know what JNLP files are
Users were confused about JNLP files. Users know what .exe files are, but not little 0.5kb JNLP files. Even if JWS is installed, Firefox users see this silly dialog asking whether to open or to save. The JNLP file on the user’s desktop does not have your application’s icon, it has a generic java icon (if Java is installed).
You cannot make the user experience much better
JWS does not allow your application installation and startup to look and feel smooth. On OSX, you might see several dock icons appear and disappear during startup. Some of them are Java icons, some are yours. There’s no way around this. Also, users are forced to see the ugly JWS download/install screen. You can minimize the visibility of this screen by using an “installer”-type JNLP file which only downloads a small installer jar.
If you want to put your application in the Start Menu or desktop, your users will see a disgusting, confusing dialog asking about “enabling desktop integration.” Most users click No, but I asked around, and many of those who clicked No said they would like to add the scheduler to the start menu, they just didn’t think it was possible. These people are Computer Science students.
The only reasonable solution is native launchers
I think the only reasonable solution for Java client deployment is to deploy native binaries (.exe, .app in .dmg, .rpm/.deb) which embed the JRE, or requires the JRE to be installed, or embeds the JRE installer in the application or in the app’s installer.
I prefer embedding the JRE because then you can have a single download page per platform and you know that it will work.
UPDATE: Kyle Cordes has posted some similar thoughts on Web Start.
April 6th, 2006 at 12:49 pm
augg….here it is, i removed the script tags….
var javawsInstalled = 0;
var javaws12Installed = 0;
isIE = “false”;
if (navigator.mimeTypes && navigator.mimeTypes.length) {
x = navigator.mimeTypes[’application/x-java-jnlp-file’];
if (x) {
javawsInstalled = 1;
javaws12Installed=1;
}
} else {
isIE = “true”;
}
April 6th, 2006 at 12:50 pm
Then do:
if (javawsInstalled) {
document.write(”Thank You. Our script has detected that your computer has Java Runtime Environment 1.4 or greater. You are now ready to download and install our desktop product.”);
document.write(”In case of problems, you can click here to re-install JRE 1.4 or greater.”);
}
else {
document.write(”Sorry. Our script has detected that your computer does NOT have Java Runtime Environment 1.4 or greater.”);
document.write(”You can click here to install JRE 1.4 or greater.”);
}
April 6th, 2006 at 12:55 pm
You might also want to invest in this book..it gives ways to customize the installation:
Java Deployment with JNLP and WebStart (Paperback)
http://www.amazon.com/gp/product/0672321823/ref=sr_11_1/102-1577175-0526564?%5Fencoding=UTF8
April 7th, 2006 at 2:39 am
Been there, done that. I had the same awful set of experiences, and I must say that jdk1.5 have improved some bits but it’s still unusable. I even have downloaded the source, and must say it’s awful (like coded by a bunch of newbies, periodically replaced). No wonder it has so many undocumented features.
The alternatives I have seen so far:
* OpenLaszlo + Flash
* Web 2.0 (AJAX / RSS + newsreader)
* SWT + eclipse update.
(I have not tried the third yet, but am fairly sure it would work). The actual choice depends on your more detailed needs.
April 7th, 2006 at 4:41 am
—>>jdk1.5 have improved some bits but it’s still unusable.
Do you mean that you don’t know how to use JDK1.5? It think that Sun Java Documentation should be a good start.
April 7th, 2006 at 6:43 am
I feel your pain. However looking at your list of alternatives, I’ve actually done two of them. OpenLazslo and Eclipse Update. Fact is, there’s always someone out there who has some weird configuration that you simply can’t fix. Now speaking about AJAX, well just make sure use a javascript library that works across all browsers.
Carlos
April 7th, 2006 at 5:08 pm
To detect Java, simply have a tiny applet that links to your web start application. Inside the applet tag, link to java.com so non-applet users can install the JRE (which is only like a 7 MB download now with the Java 5 compression).
But in general, JWS really only makes much sense in environments where you know all the clients do have Java installed, e.g. an intranet.
April 8th, 2006 at 10:32 am
If it can’t be done in the browser, make it a native app with SWT+gcj.
cheers,
dalibor topic
April 9th, 2006 at 9:01 am
Why I will also never deploy with Java Web Start again
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…
April 9th, 2006 at 1:32 pm
Well, my money is where my mouth is… We just launched a quiet beta of a large scale application based on JWS. Some of your points are valid but most of your points are rather extream and you didn’t specify the constraints of deployment (i.e. JVM versions etc…):
1. Java Web Start doesn’t work for a large number of users:
This was true for older versions, since Java 5 I haven’t run into a single problem. Sure we are still in quiet beta so I won’t say this is resolved :-)
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.
April 18th, 2006 at 5:22 am
We are a company running a bridge server with 10000 users. We have used JWS to deploy our client since 2002. Ir has been a great success!! If an applet was an alternative then I would rather do that, but the alternative is an installation on the users PC. It is so much easy’er to use JWS and most of your problems comes from bad implementation. There are several ways to do all automatic and do it in such a way that the users do not get mixed in what to do. JWS is a great idea and works as good as possible compared to an ordinary install. And also you have the benefit of always have client to be in synch with the latest version avail. At http://www.topbridge.com we have choosen an half automatic install and only received great feedback from our customers.
April 20th, 2006 at 9:02 am
My experiences with Java Webstart are more along the lines of Shai’s, so maybe you should try Java 5. Also, many of your problems of no detection and not updating the app are due to Internet Exploder. We have encountered a few strange issues that all come down to IE’s cache settings. This is a problem you would even experience with web apps since you can’t control the browser settings on the client machine. Another problem with the updates could be due to the timestamps of the jnlp and jar files. A better way to handle when and what gets updated is to use version based downloads. This way you specify a version number for all jar files in the jnlp file. Only those that are a higher version get downloaded. Take this a step further by providing the older version jar file along with the new one and you can use jar diffing to only download partial jar files. Also, to mitigate the download size, you can easily provide pack200 compressed jar files so any client with JRE 5.0 will get the compressed jar file. Currently, these features require the JnlpDownloadServlet to function. You can find out more information about Java Webstart, Pack200, and JnlpDownloadServlet at this site: https://deployment.dev.java.net/
April 20th, 2006 at 9:03 am
Can you elaborate on your comments that JWS “doesn’t work for a large number of users”? How does it fail? I don’t understand why the number of users changes anything.
April 20th, 2006 at 11:02 am
I understand the problems you’ve hit with JWS, and I would say you are hitting the “growing pains” of a still fairly immature technology. I know JWS has been out now for quite some time, but consider its progress and growing pains in comparison with the pace of other deployment technologies, and it doesn’t look so bad. Quite good actually!
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? ;-)
April 20th, 2006 at 11:41 am
Having deployed two applications with web start using 1.4 and 1.5, I’d say my most recent and largest complaint is the poor handling of certificates when downloading from a secure (HTTPS) server. Man, is it awful!
April 20th, 2006 at 1:01 pm
John, it just doesn’t work for a lot of people. There’s nothing special about the number of users.
April 20th, 2006 at 1:03 pm
Erik,
* I was using Java 5
* It doesn’t make any sense to say the problems are because of IE. Am I supposed to ask every user to install Firefox? I have never ever seen this behavior in a web application, so I guess it’s JWS-specific.
* I was using Pack200
April 27th, 2006 at 12:52 am
I am having only 45 users and at one time maximum three users are downloading using JWS but still the downloading dialog gets hang and progress bar remains constant eg. 60% or 80% without downloading further. What may be the possible causes for this ?