As the dust from Java One settled, I ran into an old friend who has been writing code for a LONG time (he started on an HP 2115 minicomputer). He remarked that Java was interesting in that it was a pure software movement. My friend said he had always worried about hardware, but the young programmers around him were scarcely thinking of the hardware needed for a major Java project. Java provided a pure creative environment, free from the chains of legacy code or the "suits and ties" in marketing. A Garden of Eden for creative minds.
The subject of this column is hardware for the Java environment. While this may seem like the moral equivalent of bringing a chain saw into this Garden of Eden, eventually hardware will determine usability of the Java code that we write. I'm talking about embedded markets and the commercialization of Java beyond today's applets.
Programmers of old (like my friend) remember working with the Soul of the Machine: Assembly language. Telling young Java programmers to worry about hardware is the equivalent of your grandfather's "I had to walk ten miles to school everyday through the snow" lectures. Java programmers around me don't care about the snow. They plan on taking a limo to school.
Reality lies somewhere in the middle of these extremes. We want Java to execute as close to the hardware as possible for performance reasons, but want to retain the "Eden" created with the concept of the Virtual Machine.
Let's look at the current Java world. Applets run on top of a Java Virtual Machine (VM). The VM runs on top of an existing OS, such as Windows or UNIX. The OS runs on top of the hardware platform. The OS translates Java bytecodes to native instructions on the microprocessor-based hardware. Thus, our Applets work though three levels of software to get to the hardware. This is not as efficient as it could be and will limit the performance of those mission critical Applets we are dreaming up.
What we need is the Perfect Java Machine, in which a programmer thinks virtual machine, but acts on the hardware directly. Two recent announcements show that Sun has been thinking along the same lines: Creating the Perfect Java Machine.
In May, JavaSoft announced the JavaOS™ (code named Kona) to solve part of the multiple software layers problem. The JavaOS executes Applets natively, thus eliminating the Virtual Machine layer of software, and (in theory) significantly improving performance. JavaSoft has also indicated that the JavaOS will support popular microprocessors.
Sun Microelectronics (SME) has pushed even further, announcing picoJAVA™ chips, microprocessors whose instruction set is Java bytecodes. Thus, little translation is needed from the JavaOS to the microprocessor instruction set, minimizing this layer of software. SME announced it is in discussions to license picoJAVA technology to several semiconductor companies.
People with a broad system view see both software and hardware integration at the chip level. The more stuff that can be put on a piece of silicon, the smaller and cheaper the end product. To this end, Mitsubishi showed its M32R/D Multimedia processor running Java Applets at JavaOne. The M32R/D integrates a RISC processor core with DRAM, a high speed cache, and DSP functionality on a single chip. (The author is employed at a company funded by Mitsubishi). The promise is for a Java-enabled PDA on a chip.
A picoJAVA-based product, or an M32R/D based product could be the Perfect Java Machine. Resolving conflicting issues such as performance, power, price, and integration of legacy code will determine which hardware is chosen for a given Java product. In the new world of Java, programmers will need to THINK about hardware, but not WORRY about hardware. I think my friend would settle for that.