Java SE Deployment Demystified
By dannycoward on Jun 23, 2006
I've seen and heard how my dad installs software on his computer. He pencils notes from the messages that appear on dialogs and puts them next to the phone for when he and I speak next. When prompted for a decision during an installation, he swings manically between over cautious, and wildly reckless. He has to take breaks when it gets too much. My mum has to take breaks when my dad's breaks get too much. In bleaker moments, questions like "Do you really want to exit ?" become deep, fraught and existential. As a published and decorated expert on 18th century French philosophers, there is some irony there.
One of the reasons that web applications have become so popular, is that the user experience side of their deployment, which is of course the only experience that really matters, is invisible. This simplicity opened up all sorts of avenues to continuously evolving services that would have been otherwise impossible to deploy on a CD. Despite the loss of technical self-worth my dad has endured in the face of various scrapes with word processing software, he has no trouble installing the latest version of the application that gets him cheap flights to France several times a year.
He knows how to click on a link.
Now, some people's assessment of the interaction model afforded to web applications by the browser, is that enough is as good as a feast. Other designers crave to provide tastier suppers for their end users, and turn to rich client models for the user interaction. Whereas the deployer's 'todo' list for a web application reads:
1. Make sure user has a browser (DONE !)
2. Deploy current version of application to server (ONGOING),
for a rich client, the deployer's todo list becomes a little more daunting:
1. Make sure users have necessary client software pre-installed
2. Get the application to users
3. Get upgrades and bugfixes to users
4. Remove old application from users' computers when done,
especially since a less than perfect score from your users on any one of these can lead to a nasty bout of indigestion.
In the case of Java SE, depending on whether you wish to deploy your application as an Java applet or an Java application (decided by asking: does the app need to live a life outisde the confines of a web page ?), you have twin technologies in Java SE: Java Plugin and Java Web Start plus some help from NetBeans, that aim to bring much of the simplicity of web application deployment to Swing application deployment. Launching equals clicking a link. Let's take a look at your deployer todo list in this case.
1. Make sure all users have correct Java SE runtime.
The industry has done a lot of work on this over the years; about 9 out of 10 of every new PCs now coming prebundled with the JRE. But for the 1/10 case or for the cases where your application requires a different version of the JRE, we've added the Java Auto update facilities to Mustang. This means with a little extra work on the launch page (either like this, or like this) we've made sure you can make sure my dad has the right Java SE runtime, or help him to install one if not. Of course, since he's on his windows PC, he may need to accept an ActiveX control, so let's hope he's feeling optimistic.
2. Get Java SE application to users
Now once my dad clicks on the link to your application for the first time, he may be presented with some dialogs. OK, some may be there for reassurance, and others may present choices, for example if you need the application to access resources on the computer, or ask my dad to confirm he trusts the source of the application (fingers crossed !). For Mustang, we gave them a pretty good makeover. Plus thanks to a number of desktop integration features, my dad should be able to start your application (faster) next time like he does other applications. Maybe he won't get distracted by something else in the middle of the process because the download might be a little faster.
3. Get application upgrades and bugfixes to users
Of course if you chose to go the applet route, I don't need to explain to you how this works. For applications deployed with Java Web Start, Mustang smooths this update path with an improved update policy. The old policy risked freaking out my dad out by suddenly going online when he started your application because it was doing an update check. Apart from anything else, my mum might have been using the phone. Yes, they are still on dial-up.
4. Remove Java SE application from users' computers when done
I will confess, this is something my dad will never need to know, and in any case for Java applets this happens every time my dad moves away from the web page that launched it. Or when the applet cache finally gets cleared. But for those who do care, Mustang improves the integration between applications installed via Java Web Start and the Windows Add/Remove software management tool. So if you found the entries pretty cryptic for J2SE 5.0, take another look once you've moved to Mustang for a pleasant surprise.
Deployment of a rich client application is still more work than for a web application, so I hope your users like the richer model when they run it. I think for Mustang we've made some important incremental improvements that should keep my dad from scratching his head. Did you need another reason to upgrade ?
However you deploy your applications, just don't forget that for every user like my dad, who generally assumes any technical problem is a mystery of his own making, there's one who will kick your application to the curb, there's one other who will burn off any money you hoped to make from the application by sitting on hold on your support line, and there's another who knows how to escalate his or her frustration to your boss.
And finally, they are all just people. As Voltaire said, "All men are born with a nose and ten fingers, but no one was born with a knowledge of God.".