Embedded processors span a wide range, from tiny 4-bit microcontrollers all the way up to 64-bit current sinks. Both chips and cores find themselves employed in systems with varying degrees of real-time requirements. In the middle of these spectrums, and most typical of today’s embedded designs, are the many soft-real time systems built around 32-bit processors. These are precisely the systems that should benefit from the recent completion of the Real-Time Specification for Java (RTSJ).
Having spent too much time in my career debugging silly typos because of C’s weak syntax rules; porting pieces of code from one RTOS’s threading API to another; keeping track of compiler differences related to the size of primitive data types and the order of bitfields; and trying to learn all the ins and outs of C++’s overly-complex brand of OOP, I was taken with Java right from my first encounter with the language, in 1996. When I attended a discussion about making Java suitable for real-time use about a year later, at the National Institute of Standards and Technology (NIST), I learned I wasn’t the only embedded programmer who’d taken a liking to this new language.
Of course, the reason we were all drawn to that discussion was because Java was decidedly not ready for real-time. As the Java language had moved out of its R&D origins at Sun and become popular with Web and enterprise application developers, its standard libraries had grown appreciably and its basic definition had become far too loose. For example, the built-in priority-based threading API, which should have proved useful as a basis for real-time software, had by then been dumbed down to the point that even those the few scheduling rules weren’t enforced by most JVM (Java Virtual Machine) implementations.
A result of that initial NIST meeting, and several working group sessions that followed, was the consensus document “Requirements for Real-Time Extensions for the Java Platform”. This document captured the opinions of experts at more than fifty companies and organizations (as well as the Department of Defense, which was seeking alternatives to Ada) on the subject of real-time software. It ended by stating a baker’s dozen goals, plus derived requirements, for any eventual real-time Java specification.
Last November, the real-time Java spec we hoped for then became a reality. So many folks wanted to see a real-time version of Java, in fact, that the RTSJ was the very first effort (JSR-001) to come out of the Java Community Process. (Even the language’s creator, James Gosling, signed up to help out.) Led by IBM, the work of the so-called Real-Time Java Experts Group resulted in a specification that describes how a real-time Java Virtual Machine must behave, a reference implementation, and a testing compatibility kit.
Among other things, the RTSJ addresses scheduling, synchronization, and garbage collection. For good measure, it adds a standardized way to peek and poke physical memory (and, thereby, memory-mapped peripheral status and control registers) and high-resolution timers to the Java libraries. By setting only a minimum standard in many areas, it also leaves the door open for advanced/alternative real-time schedulers to be offered by competing implementers.
I want to take this opportunity to thank all of those who have rolled up their sleeves and brought us closer to real-time Java. Your efforts have been worthwhile and the results look promising. Keep up the good work.
Unfortunately, we’re not done yet. The effort to bring Java to a wide range of embedded systems must include developing small (50-100KB) JVM/RTOS combinations that are compatible with RTSJ. Something along the lines of a real-time version of Sun’s KVM ought to do the trick. I’m confident we’re getting close to that final solution.
