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
|Java||Soft real-time||Hard real-time||Safety-critical|
|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|
|Manual memory||Not allowed||Not allowed||Allowed||No de-allocation|
|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|
|Courtesy of Aonix|