Under the auspices of the Open Group, Java is taking a turn for the worst--solving the worst programming problems, that is. The Safety Critical Java and Mission Critical Java standard efforts are under way. These specs are based on the Real Time Specification for Java (RTSJ), which was developed by the J-Consortium's (www.j-consortium.org) Real Time Java Working Group.
Unfortunately for many embedded systems designers, RTSJ is more than they need. For example, the scheduler is an option. This is great for design flexibility, but it makes the platform a moving target. Safety Critical Java prunes the RTSJ, keeping it functional while reducing complexity.
The new standard also makes a number of additions. Some address scoped memory and other eliminated features. Others, like explicit variable lock definitions, force lock overhead out into the open, where conventional Java does it implicitly.
Kelvin Nilsen, chief technology officer of Aonix (www.aonix.com), is one of the architects of the Safety Critical Java specification. He notes that the proposal is large, over 200 pages. But it spells out the details for a robust, embedded Java, including its class hierarchy. The detail is necessary to eliminate any vagueness or implicit implementation problems that arise in standard Java.
The bottom line is that Java can span the market from a static, fixed allocation embedded environment to a dynamic, server-based Web service. Safety Critical Java will deliver better performance while eliminating many of the programming problems encountered with C++ and other embedded languages.
The schedule for the Safety Critical Java project targets 2005 for implementations. The specification should be completed by the first quarter of 2005, with compliance tests and reference implementations thereafter courtesy of Sun Microsystems (www.sun.com).
The Mission Critical Java project has a longer, less specific timeline since it will be based on the Safety Critical Java specification. Aonix's JRTK targets the mission-critical arena, but support for the standard will have to wait until the specification is available.
Meanwhile, RTSJ is there and ready to use, as are products from a wide range of vendors. Java may not meet the requirements for all embedded applications, but it definitely fits into the embedded world right now with the likes of JRTK.
| - SOME CRITICAL REDUCTIONS - |
|
Pick Only One Scheduler RTSJ allows a variety of schedulers to be used in a system. Keep things simple with a single, priority-based scheduler. |
|
One Thread Type Heap, no heap. Real time, not real time. The presence of too many options makes it hard to analyze a system. Reducing the selection to the no-heap, real-time thread makes applications more predictable. |
|
Eliminate Scoped Memory Scoped memory provides a powerful mechanism for memory management, but it has lots of overhead. Check out stack-allocat-able memory instead. |
| + SOME CRITICAL ADDITIONS + |
|
Stacking Memory Scoped memory is going away. Stack allocated memory provides an alternative for explicitly managed memory. It does not require runtime checks like scoped memory, although it is less flexible. Still, its functionality is more than adequate for most applications. |
|
Its A Lock In theory, every Java variable can be locked. Most Java implementations dynam-ically allocate locks when a variable is locked. This is definitely a problem for real-time applications since the setup time is variable. The new alternative is to require explicit lock interface support for classes whose objects will be locked. No interface, no lock, no overhead. |
|
Fixing Class Variables Dynamic class loading can wreak havoc on many embedded systems. Most real-time Java implementations allow class variables to be initialized before runtime. The new standard will formalize this so that all class variables will be set up before runtime. This also eliminates race conditions that can occur with dynamic class loading. |