I first encountered Java in 1996. At the time, I was working for a company that built satellite telemetry equipment. Parts of this were real-time/embedded—mostly VME boards running VxWorks. But other parts of the data post-processing were done on Sun workstations. I became interested in the language when, pulled aside from my usual embedded programming responsibilities for several months, I was enjoined to help write some workstation software in Java. It was love at first compile.
I was immediately wowed by the Java language. I loved that it’s basic syntax was very like C’s, but that its creators had addressed many of that languages inconsistencies and pitfalls. I was also impressed at how much faster it was to program in Java than C++, a language I’d tried to love but never been able to. At first blush, Java also had some cool features for embedded programmers—things like fixed-width integers, a portable binary format, guaranteed protection from memory leaks, and built-in support for threads and synchronization (no more porting your embedded code from one RTOS API to yet another).
The only problem was that I loved embedded programming more—I still do. So I’ve been on a five-year odyssey of hope; wanting to use Java in my embedded programming, but never having the opportunity to do anything more than experiment. I’m still convinced the language is awesome and that embedded programmers using C++ would benefit heavily from switching over to it. However, the priority in our field is always on shipping a product vs. hoping some new language or tool will make the process easier.
To find out where things stand with embedded Java today, I organized and moderated a panel called “Is Java Ready for Embedded Use?”, which took place last night at the Embedded Systems Conference in Boston. The panel consisted of two real-time Java gurus and four embedded programmers who’d recently used Java technologies from Wind River, Newmonics, aJile, and other vendors. Here’s what I and the other attendees learned from the panelists.
The most important thing we learned was that people are now building real systems (and even shipping some of them!) with Java. Of course, the Real-Time Specification for Java (RTSJ) is still several months away from having a complete reference implementation (RI) and testing compatibility kit (TCK), so today’s embedded Java users are mostly from the “no-real-time” side of the house.
A common current use for Java is as a user interface engine. In other words, the real-time and device-specific stuff is still being done in C. A Java Virtual Machine is simply added to the system as a mechanism for executing complex, and perhaps field-upgradable, user interface threads. The big advantages are that: (1) any competent Java programmer can be enlisted to produce that part of the embedded software, and (2) feedback from marketing and target customers can be sought and incorporated long before the actual hardware is complete. Wind River says that about 10% of its RTOS customers are also licensing a JVM from them and using it for such purposes.
Another option is to base your system design on a Java processor and write all of the firmware in Java. The processors from aJile Systems, in particular, support many of the features recommended by the draft RTSJ spec. This means that real-time programming in Java is available today, in quantity. And aJile has already stated they’ll conform their technology to the final spec, as soon as the RI and TCK are available.
It should be extremely interesting to watch the embedded Java space over the next one to two year period and to see how an increasing number of users will take advantage of its many great features.