When Java first appeared it seemed that it would revolutionize the way client software was written and deployed. As it turned out, Java has taken off more as a way of writing server software. In this article I argue that Java is more suited to server software because it has more to offer technically-minded users than naive ones with Java applications being easier to write than normal applications but more difficult to install. I conclude that Sun would do well to pursue a two-track approach of developing the pure-Java platform but also push Java as a language for writing native applications in the way Microsoft has wanted to.
For most people their first exposure to Java was an applet embedded within a web page. Applets were to be a useful new way for users to access software. It would be stored and managed on servers and run safely on the client. In fact, much of the Java security model seems to have been informed by the existence of applets. Five years on, applets are a pretty dead technology. Even worse, there seem to be no major Java applications aimed at the average user.
Of course, Java has not been a failure in other regards. The Java enterprise technologies have been a big success and many corporations are using Java to build web-sites and transactional, database-driven distributed systems.
It's easy now to ask a question: what is it that makes Java a client-side failure and a server-side success? We can find part of the answer by looking at the few situations where Java has succeeded on the client.
There are a few typical examples of substantial GUI-based applications written in Java:
These are all very substantial applications but they all have one thing in common: they're aimed at people who write software. JBuilder and Forte are Java development tools, Together/J is a software design tool.
Now we've hit the crux of the Java situation. It's nothing to do with whether your machine is a client machine or a server machine but to do with what kind of user you are. If you're a software developer then Java is the best thing since sliced bread. If you're a ordinary user Java is more trouble than it's worth.
Java has been a success with programmers because it strikes a good balance between ease-of-use and power. Language facilities such as garbage collection and threads and the presence of a large, well-designed standard library make it very easy for programmers to get up and running. It also means that the language doesn't run out of steam when you're doing the difficult things.
The problems come when you try and deploy this software. Support for Java has varied enormously. Different operating systems support different versions of the language, often with their own particular bugs. Browser support has been particularly bad, lagging far behind the operating systems. The situation is getting better all the time but there is a greater problem: the lack of a "pure" Java runtime in the standard Windows installation. Whenever a pure Java application is deployed on Windows we must make sure that a Sun Java runtime is already installed or will be installed with the application. Microsoft supply there own virtual machine but it is a partial implementation of an earlier version (1.1) with proprietry Microsoft extensions.
While the issue of Java support may look bad, if you're a programmer or a system administrator this situation merely seems like an inconvenience. Installing a Java runtime isn't difficult, and it's easy to find out what version of the runtime is supported on a particular platform. For the naive user though this is a big problem. It's an extra step before you can run any Java application, another thing that can go wrong
There is another regard with which Java isn't good for writing client-side applications and that is because the Java platform doesn't work seamlessly with the platforms it is built upon. You can cut and paste between native and Java applications but drag and drop is a recent addition and there is currently no default mechanism for associating Java applications with particular file types. For server software this isn't an issue, but if you're writing an office suite in Java it will be a major irritation for your users.
There are two approaches to writing Java applications. Sun's view is that of pushing 100% Pure Java where you could write an application that would run the same on any Java platform. The Microsoft approach was that Java was a great way of writing applications that used native operating system libraries and components. Each party viewed the others approach as a threat, but from the developer's perspective both approaches seem to have advantages and could be seen to be complementary.
The Java platform is still maturing and until it integrates seamlessly with the platforms upon which it sits it will never be a good basis for consumer applications. But the existance of a large cross-platform library is still a selling point for Java. What would be useful for developers would be a situation where they could write their applications mainly using the pure Java libraries but use a small number of system-specific calls to provide seamless integration. Additionally, sometimes the Java platform might not be considered mature enough for the kind of application being written, i.e. for games and multimedia, and a developer might reasonably choose to write it in a completely platform dependent way with the Java libraries merely filling the gaps. Either way, the option of two very different development styles in a single language would make Java extremely attractive to a broader audience than the one it currently has.
Currently there is only one vendor pushing this policy: Apple. MacOS X will contain a pure-Java runtime but also complete native APIs: Cocoa and Quicktime. What they will give developers is a platform where they don't have to choose which approach suits their projects, they can draw from both. Fundamentally, developers should not care about political stances like "100% Pure Java and nothing else", only pragmatic approaches that allow them to get the job done. Hopefully, at some point Sun will realise this and give developers what they want.
| Date | Version | Comments |
|---|---|---|
| 19th July 2000 | 1.0 | First version. |