Electronic Design

Java For Critical Jobs

Standard Java has been found unsuitable for many embedded applications, but real-time and mission-critical enhancements are remolding the language. Hard real-time Java was formalized in JSR-1. It specifies a very flexible scheduling system (see "Will The Real-Time Java Please Stand Up?" ED Online 3156).

The Open Group is looking to make more changes to Java so that it can meet safety- and mission-critical applications. The table shows how various Java flavors differ. The safety-critical standard already has a reference implementation, a drafted standard, and a suite of compatibility tests.

Use of real-time or safety-critical implementations will require developers to change how they work, but the basics remain the same. Java syntax also remains unchanged. However, some classes are out of bounds, and some operations must be performed by a different set of classes.

Alternative classes tend to be restricted to memory and task management. For example, soft real-time support implements a real-time garbage collector that runs asynchronously to keep ahead of the need for free memory. This prevents the delays associated with many desktop Java garbage collectors. But this isn't good enough for many applications, so other Java alternatives simply don't support garbage collection. This can lead to memory leaks, a problem familiar to C developers. On the other hand, embedded developers are used to dealing with fixed memory allocation, where determinism is very important.

Deterministic operation is one reason for providing better control of scheduling and priorities. Changes will let developers address priority inversion problems that can occur with standard Java.

Asynchronous event transfers let one task interrupt another task. Safety-critical Java doesn't support this feature, which is useful in real-time applications, because it's incompatible with accepted practices for safety certification.

Safety-critical and real-time Java isn't required for every embedded Java application, but it's worth investigating the alternatives. Interestingly, safety-critical implementations tend to be small so certification is manageable. Basic J2SE libraries exceed 4 Mbytes. Using safety-critical platforms can result in smaller and faster products and more reliable implementations. Applications may become faster, too.

The Open Group

Standard Mission-critical Java
Java Soft real-time Hard real-time Safety-critical
Standard Yes Yes Yes Pending
Library support J2SE J2SE Subset of CDC Restricted CDC
Library size About 4 Mbytes About 4 Mbytes About 16 kbytes About 16 kbytes
Performance vs. 30% to 70% 25% to 60% 85% to 95% 85% to 95%
C-based memory 16 Mbytes 16 Mbytes 64k to 1 Mbyte 64k to 256 kbytes
Garbage collection Variable Real-time None None
Manual memory Not allowed Not allowed Allowed No de-allocation
Stack allocation No No Yes Yes
Class loading Dynamic Dynamic Dynamic Fixed
Thread priorities Variable, Fixed priority, Fixed priority, Fixed priority
priority boosting distinct priorities, distinct priorities, distinct priorities
time slicing time slicing
Priority inversion None Priority Priority inheritance, Priority ceiling
avoidance inheritance priority ceiling
Asynchronous No Yes Yes No
event transfer
Courtesy of Aonix
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.