Java arose from the vision of the network as the computer. It was intended to be a language by which applications could run on any machine without changes. The rallying cry "write once, run anywhere" fired the imagination of developers worldwide. But has Java delivered on its promise?

Java certainly hasn't taken off in the network application for which it was designed. But oh, did it have promise. The idea of an application language that ran on any computer equipped with a Java Virtual Machine (JVM) seemed to solve a lot of problems.

Individual computer systems would no longer need to maintain their own local storage of applications. Applications could come through the network, run on the machines, then be discarded from local memory when not needed. The IT managers wouldn't have to maintain multiple versions of the same application to accommodate the heterogeneous mix of machines in use. There would no longer be a need to upgrade dozens of computer systems when new revisions of applications came out. One copy, in Java, on the network server would serve everybody.

But the idea floundered in practice. Because it is an interpreted language in network applications, Java code runs much slower than native code. In some cases, it ran as slow as one-tenth the speed of native code. This proved bothersome for users. Despite processor clock speeds that have pushed beyond 1 GHz, applications have gained enough complexity that the speed differential between Java and native code has remained noticeable and annoying.

Then there's size. Java code tends to be more compact than native code, but it's not compact enough. Applications have ballooned in size, so that downloading the application from the network each time it's needed became impractical. Even at megabit rates, downloads take more time than users have patience for.

Java did find a niche on the Internet. There, the ability to access a diverse variety of machines over a network with a customized program was essential because there was no practical alternative. Yes, programs of significant value, such as RealPlayer, could follow the traditional course and require local versions with local installation, but smaller utility programs couldn't afford such barriers to their use. They would be ignored. Java fills the gap for them, allowing such programs to execute reliably on diverse machines after a quick download from the network.

For embedded system designers, Java had a different appeal. The language itself strikes a balance between the ease of C and the complex object-oriented power of C++. Java is object-oriented, but avoids some of the more dangerous constructs of C++, making it easier to code reliably. The structures of Java that make it suitable for network-based transmission and installation added to its appeal. Embedded designers envisioned network-connected devices that could be customized by the program they receive from the network. A set-top box, for instance, could be a DVD player one time, and get converted to a game machine later, all based on the Java code they were running at the time.

But did Java deliver on this promise? For embedded designers the short answer is "not really." There were a few problems with Java that still needed ironing out. Instead of "write once, run anywhere" Java in embedded systems acted more like "write once, debug everywhere."

There are several things about Java that make it maladapted to embedded applications. One is its inability to provide deterministic operation. Java's background garbage collection prevents anything like real-time operation because it runs without restriction. Further, since Java doesn't have the ability to handle hardware directly, you have to add machine code segments to provide that capability. Having machine code embedded in the program eliminates the machine independence that is Java's main appeal.

Then there is the subject of classes. Java depends on local machines having a base set of functional program segments called "classes" that the code can reference. If the program needs segments not in the base set, it provides them at download. For embedded designers, that base set of classes occupies system ROM that developers would rather not use if they don't have to.

There have been efforts at defining a reduced base set for embedded systems, but there has not been widespread agreement on what should be in the set. Instead, developers have defined their own set for each system. That leaves third-party applications programmers, who are trying to develop software for these Internet-connected devices, in a bind. They cannot be certain that the classes they use in their programs will be resident on each system. So, they must provide those classes at download, which adds to code size and increases download time.

Can these problems be overcome? Many developers believe so. Java is not taking the world by a storm the way Linux seems to be, but it is experiencing a steady growth in popularity. Solutions to the problem of garbage collection and real-time operation have arisen, some devices are now available for which Java is the machine code for direct hardware access, and standards for embedded class sets are slowly being adopted. It's not as easy to use as it seemed it would be, but Java is making a place for itself in the embedded world.