Java For Critical Jobs

March 3, 2005

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 "Wil

William G. Wong

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 Groupwww.opengroup.org MISSION-CRITICAL STANDARDSStandardMission-critical JavaJavaSoft real-timeHard real-timeSafety-criticalStandardYesYesYesPendingLibrary supportJ2SEJ2SESubset of CDCRestricted CDCLibrary sizeAbout 4 MbytesAbout 4 MbytesAbout 16 kbytesAbout 16 kbytesPerformance vs. 30% to 70%25% to 60%85% to 95%85% to 95%C-based memory16 Mbytes16 Mbytes64k to 1 Mbyte64k to 256 kbytesGarbage collectionVariableReal-timeNoneNoneManual memoryNot allowedNot allowedAllowedNo de-allocationde-allocationStack allocationNoNoYesYesClass loadingDynamicDynamicDynamicFixedThread prioritiesVariable,Fixed priority,Fixed priority,Fixed prioritypriority boostingdistinct priorities,distinct priorities,distinct prioritiestime slicingtime slicingPriority inversionNonePriority Priority inheritance,Priority ceilingavoidanceinheritancepriority ceilingAsynchronous NoYesYesNoevent transferCourtesy of Aonix