Skip to main content

Desktop Deployment Ideas

Posted by javakiddy on August 8, 2006 at 9:11 AM PDT

Thanks to JavaDB there's been a lot of noise recently about Java SE (is that what we're supposed to call it this week? :) and end user experience. Specifically, the time it takes to download the JRE onto a desktop computer, versus so-called rival technologies such as Flash. At the heart of this debate is a classic catch twenty-two conundrum: the more feature-rich SE becomes, the bigger it gets and the less likely it is to be seen as a short, sharp, convenient download by 'Joe Surfer', our archetypal end user.

It seems a lot of people agree that something should be done, but few go as far as to throw any concrete ideas into the metaphorical 'deployment hat'. I have little experience of developing deployment software. My only real interest in this field is as someone who writes Java applications, and therefore has to deal with desktop deployment issues as they currently stand. So for what it's worth, in the hopes of putting some extra flesh to the bones of this debate, here's a few random thoughts of mine...

Problems, problems

Firstly, let me list a few desktop deployment issues as they pop into my head. I doubt this will be an exhaustive list, but for the purposes of this discussion it gives us something to work from:

  • Compared to other 'downloadables' the JRE is large, particularly if the download prompt comes via means of a web browsers, where users are accustomed to plugins the size of Flash.
  • Double clicking a Jar file launches a zip utility not the Java application in question on too many desktops. Because it is just a 'special case' zip file, the Jar file type is stolen by other software.
  • In an application broken up into many Jar files, it isn't immediately apparent which is the main executable, and which are merely supporting libraries.
  • All too often, platform specific wrapper scripts are needed to set properties, class/lib paths, and other sundry startup tasks.
  • With no central repository for packages, each application bundles the same Jar files over and over.

Below I've outlined a few random thoughts on these issues, and how they might be addressed. Not fully-formed solutions, mind, just thinking aloud!

Only one version number: 7.1 means 7.1 .

Breaking the JRE up into chunks is the obvious answer to the download size problem. Who cares if the JRE features a database or not, if it only needs to be downloaded on demand? But let me cover one small worry I have about the notion of breaking the JRE up into bite sized pieces: it's not something I think will actually happen, but worth noting all-the-same just to get it on the record...

But what I don't want to see is a situation where desktop programmers have to juggle separate version numbers for each of the component 'chunks' in a JRE, because components can be downloaded in a mix-n-match fashion. If a JRE reports version 8.52 then it should have exactly the same functionality, including the same quirks, as every other 8.52 on the face of the planet (within reason!)

Any version numbers used internally to identify each JRE component should be completely hidden to the Java developer. Obviously some components may be copied over verbatim from one JRE release to the next -- particularly if a release is a bug/security fix which only impacts on a single package. There's scope to share components already installed between versions, but all this should be transparent to the developer: for a given JRE version there should always be a predictable and uniform set of components.

A single cache for Jars

Basically this is a common repository of packages, which all Java applications can draw upon and extend. For example: rather than every application which utilises the JavaDB needing to bundle it with their application, the application merely requests a specific version of JavaDB, gives a standard URL from which it can be downloaded, and if it isn't already in the repository then the JRE will download and add it. This helps keep the size of each Java application down.

We already have something like this with WebStart. It needs to be extended more widely to include non-WebStart applications.

JEXE: A new(ish) way to launch Java apps from the desktop.

This is where I pull the above two point together...

I've pondered for some time now the value of having a platform neutral startup 'script', perhaps rule-based XML file like Ant's build.xml, specifically for starting up Java programs.

This solves a multitude of sins. It could be given a unique extension (let's say JEXE, short for _J_ava _Exe_cutable, for want of a better name) which would immediately set it apart as THE icon to double click to start up an application. It also side-steps pesky zip utilities which steal the Jar file type. Plus it might also take most of the classpath/properties/etc configuration out of an embedded manifest, and places it somewhere more readily accessible.

As I see it, a lightweight JEXE 'script' would run prior to the startup of the JRE, and would allow the local environment to be queried and the JRE to be configured before it was formally started, including adding/replacing/removing elements in the class and lib paths and setting or unsetting properties. It would also be a place where the necessary JRE components and third party packages could be listed, for download before the application began.

Unlike JNLP files, a JEXE 'script' would be capable of querying its environment and acting accordingly. For example, an application which makes use of the tray icon API might have a JEXE 'rule' to query if the JRE version is below 6.0, if so check whether the JDIC library is installed, if not prompt for the download of a version appropriate to the native environment, and finally modify the classpath and library to add the JDIC files.

The JEXE file could also arrange for different versions of packages to be included on the classpath, depending upon the environment or other factors, like what other packages are currently installed. For example, Oracle's database drivers come in two flavours, the heavyweight versions which can work with stuff like 'tnsnames' (but requires JNI) and a lightweight all-Java implementation which can't (and therefore doesn't). If it was possible to query in advance the platform architecture, JRE security policy, etc, the JEXE script could ensure an appropriate version of the packages were on the classpath when the app started.

The 'JEXE' startup script idea is a bit radical, I know, but it does seem to be an idea which might solve a lot of problems, both present and perhaps in future. I haven't really thought about how the JEXE idea can be adapted for applets, or whether JNLP could be extended so we could use the same XML format for embedded, WebStart and desktop. But I suspect the answers are out there if we took the time to search for them.

Conclusion

So there you have it. Like I say, these ideas are just 'thinking out loud', and not a coherent plan. But hopefully they might serve to further stir up a bit more debate. I know a lot of what I've written above is already covered in disparate pieces of Java technology, but I'd like to see some effort to pull it all together into a single coherent form, so deployment on the dekstop becomes a breeze rather than a minor nightmare.

Related Topics >>