The problem of old Java runtimes

The August PC Pro arrived this morning, and I enjoyed Steve Cassidy’s rant (page 174) on old versions of Java that typically litter PCs:

I’ve made it my habit to go round all the LAN’s I visit removing all older versions of Java from the machines, because the Java updater doesn’t remove them automatically.

It reminded me that I’d intended to post about this dialog, encountered when installing Accurev for a short review:

The decision here is whether to let AccuRev install its own version of the JRE (Java Runtime Environment), or to use one you already have, in which case you have to identify it. It’s a tough decision. If you follow the recommendation to install a private version, you end up with multiple different versions of Java which will likely never get updated except by the application vendor, if indeed you choose to upgrade. I understand why vendors do this: it simplifies testing and installation, and gives apps a predictable platform on which to run.

Unfortunately the downside is substantial too. In the AccuRev case it was slightly unfortunate, since the supplied JRE was incompatible with Vista and broke Aero graphics. A more painful example was when the JRE installed with APC’s PowerChute utility failed because of an expired cryptographic certificate; the consequences were extreme, and in many cases affected systems would no longer boot. See here for the gory details.

I prefer the way Microsoft handles the .NET runtime, where more than one version can be installed, but they are system files for which Microsoft takes responsibility through Windows Update. Sun installs an updater with its JRE that works for web browsers and other applications that use a shared JRE, but there are still many apps like AccuRev that install private versions.

Technorati tags: , , ,