Making Java Real -

Making Java Real


Embedded processors span a wide range. Many are 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.

Embedded processors span a wide range, from tiny 4-bit micros all the way up to 64-bit current sinks. They find themselves employed in systems with varying degrees of real-time requirements. In the middle of both 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.

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 trying to learn all the ins and outs of C++'s overly complex brand of OOP, I was immediately taken with Java when I first encountered it in 1996. When I attended a discussion about making Java suitable for real-time use a year later, at the National Institute of Standards and Technology, I learned I wasn't the only embedded programmer who was interested.

Of course, we were all there because Java was decidedly not ready for real time. As the language moved out of its R&D origins and became popular with web and enterprise application developers, its standard libraries grew appreciably and its basic definition became far too loose. The built-in priority-based threading API, which would have proved useful as a basis for real-time software, was, by then, dumbed down.

A product 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 captured the opinions of real-time experts at more than 50 companies (as well as the Department of Defense, which was seeking alternatives to Ada). It ended by stating thirteen 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 spec was the very first effort (JSR-001) spawned by 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. It also adds a standardized way to peek and poke physical memory (and memory-mapped 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. But 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.

Return to the March 2002 Table of Contents

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.