Write once, run anywhere" is probably the single-most repeated description of what Java is supposed to be about. It has been one of the cornerstones of Java's massive edifice of hype. However, like all hype, there's both truth and fiction to WORA.

The truth is that Java offers true cross-platform binary compatibility via the Java Virtual Machine and a rich set of standardized class libraries. Java has provided the ability to take an application from one platform to another without so much as recompilation like almost no other language or programming environment.

The unfortunate reality of WORA is that without a JVM and a set of associated libraries (which contain platform-specific native code), your Java bytecode isn't going anywhere. This is partly offset, of course, by the fact that for most operating systems, the OS vendors are quite willing and able to supply at least one, if not more, different JVMs for their platform. For example, at least four different JDKs are available for Windows (one each from Microsoft and IBM and two from Sun) and multiple JVMs from multiple companies. But if you're using something off the beaten track, like BeOS, you're out of luck.

The other unfortunate side effect of the WORA hype is Java's ill-fated inclusion in popular Web browsers, namely Netscape Navigator and Internet Explorer. It's true that Java's rapid explosion in popularity is due largely to the wide exposure Java obtained by being bundled into the one piece of software that just about everyone has on their computer, the Web browser. Unfortunately, as Java's abilities have grown through new features and new libraries (like Swing and Java2D), the ability to deploy real Java applications via browsers hasn't kept up. Even more unfortunately (and in my humble opinion here lies the real problem), this fact is virtually unknown to a lot of Java programmers, developers, architects and development managers. Somehow the true power of Java's write once, run anywhere abilities has become misunderstood to mean "we can ignore deployment problems ­ just run it as an applet!" In case I'm not being clear enough here, let me make it clear ­ applets don't work. Not for real applications.

The true power of Java becomes apparent when you look at real distributed application architectures using toolkits like Jini and JavaSpaces. JavaSpaces lets applications post not only data to a space shared by multiple distributed systems, but also code ­ it's a generic system that allows clients and servers (if those terms even mean anything in the context of applications written using JavaSpaces) to dynamically request just about anything. Jini is more than just a set of Java APIs, it's a vision of connecting devices together, and letting them discover each other independently and share code and data seamlessly. JavaSpaces itself is built on top of parts of Jini. In a recent interview Bill Joy, chief scientist of Sun Microsystems, admits that the concept of mobile code and a vision of Jini were in their minds when Java was originally directed onto the Web, back in '94 and '95. The concept of applets in this context is a brilliant marketing move, exposing everyone to Java and generating a huge amount of excitement. But realistically, without a mechanism for caching code and doing version management, you can't write a real application using applets. If you have a high-speed network and a small number of users, sure, they won't mind downloading a few hundred kilobytes of code (or more) every time they want to run the application. But once you have a serious number of users, a realistic, overstressed LAN and applications that are moving into the range of megabytes in size, the applet model just breaks down. Not to mention the incompatibilities between different browsers' Java implementations, making it difficult to do things like accessing the local disk or printing. And what about remote users, who are connected via low-speed links or who may spend significant periods of time completely disconnected from the network? There's a long list of problems.

None of this would matter much if no one was trying to use applets. But people are. All too often I'll be talking with a Java developer or reading a post on one of the Java newsgroups or mailing lists and I'll hear (or read) something that starts like this: "I'm having trouble with my applet. It's 947 Kb and it doesn't appear to be printing the Swing components correctly under Internet ExplorerŠ." There's probably a solution for this developer's problem, but I think it's more than just another problem ­ it's a symptom. The fact is, it's hard to deploy software. Getting applications from the hands of the development team to the hands of hundreds, thousands or tens of thousands of users is a really hard task. Which is why so many developers cling to applets in the face of so many problems ­ they're looking for anything to help them with the problem of getting applications out and kept up to date on a regular basis.

The real solution is to use a more tried-and-true deployment technology, like automatic installers, or a more sophisticated enterprise-scale application deployment solution. Unfortunately, just as deployment is often the last thing that developers think about, it's one of the last major issues that has yet to be solved for the Java community at large. "Write once, run anywhere" may be true, but getting there is still half the battle.