Java SE Deployment Demystified

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.".

<script type="text/javascript" language="javascript"> var sc_project=1666444; var sc_invisible=1; var sc_partition=11; var sc_security="3ae12059"; </script> <script type="text/javascript" language="javascript" src=""></script>

This is pretty interesting read. You're selling the improvments made to Mustang and at the same time I have the feeling that you recommend going the web app route...

Posted by James on June 24, 2006 at 07:03 PM PDT #

:-) The advantages/disadvantages of user interaction model make for a meaty - and different - discussion. Certainly the user experience of installation, which is one of many factors to consider, is usually vastly superior for web applications - and one that Java SE is attempting to get closer to with the applet and Web Start models. But of course there are many other factors to consider !

Posted by Danny Coward on June 25, 2006 at 04:04 AM PDT #

Sadly, JWS is quite broken even after ~4 major releases! We just deployed a rather HUGE JWS application and we were surprised by some of the really stupid bugs that still plague this product thats supposed to be simple.

We don't need NTLM or anything complicated, just signature verification and reliability. It seems both the product and the spec are broken, in many ways. Don't get me wrong, Applets are worse and we would probably use JWS again given the option... But we are VERY dissapointed with the low quality of JWS even under Mustang! Just so you won't blame me for flaming without examples here is a partial list of problems:

  1. Application marked as online will launch when there is no internet connection - I filed a bug on this and never got a reply, this essentially makes some networking applications completely impossible and others MUCH harder to write!
  2. Cache refresh is often necessary and when JWS fails (due to a cache failure) it presents a message as if there is an error with the application. Only when pressing on the details button it is obvious that it couldn't find a file in the cache... Why is JWS error handling code so broken after so many years???
  3. Hard to deploy - I can go on forever about this... Why in hell was the whole pack/gz servlet stupid trick required??? I can understand its usefulness for backwards compatibility but SOME of us don't need that! So our Java 5 only application has to have a servlet for the JWS jar requests. Buggy sample servlet code that doesn't work, I took the code from Sun's site and it didn't work correctly. I gave up evetually and wrote my own. Then theres the JavaScript/ActiveX... Is it so hard to package a WAR file that actually works? Plug/play?
  4. The people for whom JWS just won't work when deployed on HTTPS servers... This has been around for ages, what is the problem here? Yes, we don't NEED to deploy on HTTPS but its a perception issue of security that our customers want.
  5. If you mention cleanup... Muffins are TERRIBLE! If I want to use something like the preferences API (which every REAL JWS application I know uses) there is no technicall way for me to clean up afterwards! Is it so hard to provide an "Uninstall" callback?

The state of JWS is just sad when compared to how "simple" its requirements are. This is something that we can sell to savy users but maybe Sun needs to merge with Apple to get something that useful for your dad.

Posted by Shai Almog on June 26, 2006 at 10:03 PM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016