More importantly, IBM will finally take the wraps off its closely guarded "common code base" strategy that will allow embedded developers to move seamlessly across multiple OSes and processors with little modification to their underlying Java code, with no new investment in development tools and with no performance degradation.

To the current optimized versions of its Java Virtual Machine (JVM) and VisualAge Java tool suite for the X86, MIPS, PowerPC, and Dragonball processors, IBM is adding versions for the SuperH, ARM and StrongARM processor architectures. And to its QNX Neutrino optimization, it is adding the iTron industrial real-time operating system and Microsoft's Windows CE. "Our aim is to support all of the major and some of the minor hardware and software platforms used in embedded design today, and to continue to evolve and extend our support as new architectures and architectural variants occur in the future," said Marc Erickson, product manager for embedded systems at Object Technology Inc.

To date, developers wishing to use Java have had to make serious compromises amongst the five key features that are paramount in any embedded design: real-time deterministic response; memory space; performance; cost of development; and time-to-market. "One of the things that made Java so attractive to embedded designers originally was its portability, because it meant that costs of development and time-to-market could be significantly reduced through the reuse of code and components," said Erickson. "These issues are no longer just the domain of large companies who have numerous software efforts and multiple platforms on which they are doing development. Now even the smallest developer is faced with even standard architectures with which they are familiar spinning off market- and application-specific variants."

While the write-once, run-everywhere promise of Java implies the reuse of software intellectual property across many products, projects and platforms, a designer in the embedded world must be ready to make serious compromises. "For portability and code reuse, the cost is code size and performance compromises," Erickson said. An obvious solution is a Java Virtual Machine implementation that closely matches the underlying hardware or software platform without giving up much of the language's write-once, run-everywhere platform independence.

This is exactly the strategy many companies are now taking. RTOS vendors have Java VMS with specific embedded control operations matched to some of the specific requirements of the operating system and processors it is designed to run on. Some major OEMs have also developed JVMs to reflect the applications and platforms on which they run. Still other companies, targeting specific markets, have developed JVMs optimized for their target applications. "Often when you hear of a company offering a port to a specific architecture," said Erickson, "it originally started out as a custom project between a specific customer and a software vendor, who then turned around and offered it as a standard product."

The result, he said, is a plethora of JVMs that are to varying degrees platform independent, but highly idiosyncratic in their reflection of the design philosophies of their developers, who may not even work for the company that ends up selling the JVM on the open market. "Despite the common underpinning of Java," Erickson said, "the code base underlying them is disconcertingly diverse."

Based on proprietary algorithms and techniques for which the company is seeking patent coverage, the common code base methodology developed by IBM's OTI subsidiary allows reasonably transparent migration across multiple hardware and software platforms without significant code modification, said Erickson.

The problem at the CPU level is that processor architectures have a large degree of similarity, but also some fundamental differences in the way their interrupt structures and pipelines work. "What we have done with our common code base is study the ways in which such things express themselves in particular implementations, and determine their similarities and differences in fine detail," Erickson said. "From this we have derived a high-level description within which particular variables can be used to generate the different architectural alternatives." Then a developer, rather than writing to the underlying architecture or a high-level platform independent VM, can write code to an abstract representation of that feature of the hardware which can vary in certain tightly defined ways.

For example, a particular feature such as a task switch can be described in a structural way, and code can be generated from this, Erickson said. Then, using object-oriented techniques, the code is analyzed to derive certain behavioral characteristics. The behavior of the code is then refined and a model is generated and mapped to the particular target architecture. In addition to an abstract description of all of the hardware alternatives of an architecture, the virtual machine model also contains a description of how to build a virtual machine. "When the virtual machine model is then mapped to a specific CPU architecture, that description is used to generate a specific instantiation of the model," Erickson said. "From this, the source code for the CPU-specific virtual machine is generated."

To guarantee that the resultant virtual machine falls within the Sun Java specification, it is tested against a number of open test suites: Mauve, Modena and Plum-Hall.

The combined effect is a degree of real-time performance with the ported JVMs that has previously not been possible without severely compromising the platform independence of the Java code across hardware and software platforms, said Erickson. "There will never be the degree of platform independence implied by the write-once, run-everywhere slogan," he said. "That is a goal, not a realistic expectation. But with these new common code base procedures we can come as close as practically possible in the embedded world."