Skip to main content

Blame Java!

Posted by javakiddy on November 8, 2006 at 2:57 AM PST

A couple of incidents have happened to me in the last few days which highlight Java's desperate plight on the desktop.

The first involved a currently existing Java desktop application, a project originally developed at another university which somehow seems to have landed on my desk. The client brought the project to us, requesting a ground up re-write. The reason was made abundantly clear in the opening paragraph of their requirements document:

"The software language must not be Java, as in previous tests this has proved to be temperamental with types of hardware and various accessories."

Note how the software wasn't to blame, nor the original programmers, nor the hardware or OS. The problem is assumed to be 'Java'!The exact nature of the problems were not explained, although currently the word-on-the-street suggest it involves deployment issues: the application didn't start up at all, didn't use the correct JVM, or couldn't find its required third party libraries on the classpath.

When it comes to getting desktop applications running under Java there's an entire catalogue of woes which must skillfully be navigated. Some are indeed genuine faults with Java, due to a legacy of neglect of the desktop platform by Sun and the Java community (preferring, instead, to go after low hanging fruit on the server side.) But many are down to external factors: Microsoft's decrepit JVM hanging around like a bad smell, zip utilities stealing Jar file associations, etc.

But in the eyes of the client, these are all Java's fault.

And it's hard to argue with them, because the inconvenient truth we all have to face is that if the software had been written in C++, or C#, or VB, few if any of these issues would have occurred. The bottom line is it's very hard to write desktop software in Java which doesn't give Java a bad reputation — it's almost like you're jumping through hoops just to match basic expectations, like the software actually being able to start up!

When you compound this with all the FUD which is still lingering from a decade back regarding Java's sluggish performance, you can see why "Java" is treated in some quarters as a dirty word.

Yesterday another bundle of documents landed in my inbox. This time it was from a media company seeking feedback on a desktop application they wish to develop. Naturally I can't disclose the details (on pain of death) but given the nature of the client it wouldn't take a Rocket Scientist to figure out it may involve some form of video and audio playback. Now I've only limited experience of working directly with JMF, but my impression is of yet another desktop orientated technology which has suffered from neglect over the years.

It's a shame, because were it not for the above niggles Java would be the ideal technology to meet this client's demands. A number of their requirements seem to fit hand-in-glove with the platform's strengths. The client really wants to push the application hard, and there seems to be a large potential audience waiting. (Even better, they seem to be very progressive in their support for the Open Source movement.) But with such a high profile application, I don't want to deliver something which takes a few months of tweaking and bug fixes just to get it deployed and running reliably on Joe Public's desktop PC or Mac.

I'm looking into other options, including assessing Adobe's Flash/Flex (a technology I've never used) as to its suitability for running as a desktop application. But I'm also searching for answers on Java... Is there a 99% reliable deployment option available right now? Can JMF be trusted, and how flaky is its ability to work with native codecs on various OS platforms?

Can Java be trusted to work, first-time, every-time...?

(On a totally, completely, utterly unrelate note, this made me laugh recently. :)

Related Topics >>