As defined in the Real Time Specification for Java (RTSJ), soft realtime describes systems in which an action performed at the wrong time(either too early or too late) has some positive value even though itwould have had greater value if performed at the proper time.
The difference between hard real-time and soft real-time does notdepend on the time ranges specified for deadlines or periodic tasks.For example, a soft real-time system might have a deadline of 100µs, while a hard real-time system may have a deadline of 3seconds.
To help developers who wish to avoid the use of traditional Java'sautomatic garbage collection and instead use the scoped memoryabstractions introduced by the Real Time Specification for Java (RTSJ),the Open Group's Real-Time and Embedded Forum is developing a set ofguidelines based on making effective use of the traditional standardedition Java in combination with appropriate profiles of the Real-TimeSpecification for Java.
Following are ten basic rules for effective soft real-time Javadevelopment:
Rule 1. Use the Java StandardEdition platform
The benefits that Java brings to soft real-time mission-criticalsystems are most relevant to large, complex, dynamic applications.Since the J2ME platform represents an incompatible subset of full JSE,it does not provide access to JSE-standard COTS library components. Ifapplications require enterprise edition capabilities, obtain thespecific enterprise edition libraries that are required and run them ona soft real-time JSE platform. Alternatively, run the requiredenterprise edition functionality on traditional (non real-time) JVMplatforms which communicate with the soft real-time JVM machines usingRMI or other networking protocols.
Rule 2. Baseline a particularversion of the JSE libraries
For any given development project, it is important to standardize on aparticular version of the JSE libraries. As Standard Edition Java hasevolved, each new release adds new capabilities and expands memoryfootprint requirements.
Each new release also deprecates (or removes) certain capabilitieswhich are replaced with newer solutions. If you are working on a largeproject for which software maintenance must span many years, youprobably want to select a certain Standard Edition platform and freezethat choice. Otherwise, you will end up making many unnecessary changesto your code base just to maintain compatibility with the ever changingdefinition of the Java platform. Document this decision to alldevelopers and managers.
Rule 3. Follow “best practices”recommendations for Java development
The software quality measures are very similar for soft real-time Javaand traditional Java. Unless specified to the contrary, follow theaccepted guidelines for writing portable and maintainable JSE code.
Rule 4. Use JFace and SWT forgraphical user interfaces
Most mission-critical software does not require graphical userinterfaces. If soft real-time systems do require graphical userinterfaces, use the open-source SWT and JFace libraries instead of theproprietary AWT and Swing components. SWT and JFace run in less memoryand run faster than SWT and Swing.
Rule 5. Use cooperating hardreal-time components to interface with native code
The JNI protocol introduces significant data marshalling overhead whenobjects are shared between the Java and native environment.Furthermore, the sharing protocols may expose Java objects and”private” virtual machine data structures to undisciplined Ccomponents, introducing the risk that misbehaving C code willcompromise the integrity of the virtual machine environment.
Experience of existing customers in several real projects involvinghundreds of man years of development document that these risks arereal, having cost development teams significant effort and calendartime to correct errors introduced into the Java environment by Cdevelopers writing JNI components. Better performance and strongerseparation of concerns is realized by implementing all interfaces tonative code as cooperating hard real-time components as defined by thehard real-time RTSJ profile.
Rule 6. Use cooperating hardreal-time components with performance-critical code
If the throughput of certain soft real-time components is notsufficient to meet performance requirements, implement the requiredfunctionality as cooperating hard real-time components as defined bythe hard real-time RTSJ profile. Because the code generation model forhard real-time components does not need to coordinate with garbagecollection, these components generally run two to three times fasterthan soft real-time Java components.
Rule 7. Use cooperating hardreal-time components to interact with hardware devices
If the soft real-time component needs to communicate directly withhardware devices which are not represented by operating system devicedrivers, implement the device driver as a cooperating hard real-timecomponent as defined by the hard real-time RTSJ profile.
If the operating system provides a device driver that representsthis device as a file, use the standard java.io or java.nio librariesto access the device. If the operating system provides a device driverwith a different API than the file system, use a cooperating hardreal-time component to implement the interface to the device driver.
Rule 8. Restrict the use of”advanced libraries”
Certain standard Java libraries are not available in certain embeddedenvironments because the underlying operating system or hardware ismissing desired capabilities. Among the libraries that may not beavailable on all platforms, listed in decreasing order of portabilityconcern, are:
JFace and SWTlibraries: These graphical libraries are only available onsystems that have graphical hardware and the SWT integration softwarerequired to drive the graphical hardware.
java.niolibraries: Many embedded operating systems do not supportasynchronous I/O.
java.iolibraries: Some embedded targets have no notion of stdin,stdout, or stderr. Some embedded targets have no notion of non-volatilefile storage.
java.netlibraries: Some embedded targets have no network connectivity.
Recognize that the use of these libraries may limit the portabilityof code and may contribute to the future maintenance burden.
Rule 9. Isolate JVM dependencies
Existing soft real-time virtual machines differ in how they supportcertain important mission-critical capabilities. Wrap all JVMdependencies in special classes that can be given extra attention ifthe code must be ported to a different JVM. Specific services thatrequire this handling include:
A) High-precision timingservices: obtaining real-time with greater precision than 1 ms;drift-free sleep(), wait(), and join() services.
B) CPU-time accounting: Howmuch CPU time consumed by each thread? How much CPU time is consumed ateach priority level?
C) Garbage collectionpacing: How to monitor the memory allocation behavior of theapplication software and the effectiveness of GC? How to schedule GC tomaintain pace with allocation rates?
D) Scheduling: If a virtualmachine offers high-level scheduling support, such as earliest-deadlinefirst or maximum accrued utility scheduling, the scheduling andsynchronization services should be isolated within a centralized API.
Rule 10. Carefully select anappropriate soft real-time virtual machine
One of the most important decisions in determining the success of asoft real-time Java development effort is selection of a suitable JVM.Each development project has unique requirements and constraints, so itmay be necessary to independently evaluate the relevance of variousavailable virtual machine products for each development effort. Inselecting a virtual machine, consider at minimum each of the followingissues:
A) Real-Time garbagecollection should have a maximum preemption latency and should beincremental so that when the garbage collector is preempted by higherpriority application threads, it can resume with the next increment ofwork when the application thread relinquishes the CPU.
B) The garbage collectorshould defragment the heap in order to assure reliable long-runningoperation or should provide some alternative mechanism to avoidreliability problems resulting from fragmentation of the heap. And itmust accurately reclaim all dead memory rather than reclaiming only aconservative approximation of the dead memory. Finally, it must bepaced to assure that memory is reclaimed at rates consistent with theapplication's steady-state demand for new memory allocation.
C) All synchronization locksmust implement priority inheritance. All wait queues must be orderedaccording to thread priorities.
D) The virtual machine needsto provide monitoring facilities to allow supervisory threads toobserve and measure the real-time resource requirements of individualcomponents. Among required capabilities are the ability to determinehow much CPU time is consumed by particular threads, how much CPU timeis consumed by the garbage collection thread(s), the rates at whichparticular threads are allocating memory, and the total amount ofmemory being retained as live.
E) Determine the releaselevel of the J2SE libraries required for a particular project andassure that the vendor is able to support the desired library versionthroughout the duration of your development project.
F) Assure that the virtualmachine provides libraries for high-precision time measurements, andfor drift-free wait(), join(), and sleep() services.
G) Assure that the virtualmachine is supported by appropriate Ahead-of-Time compilation andlinking tools if the system is statically compiled and loaded.
H) If the system mustdynamically load components, assure that the dynamic class loader canbe configured to run at lower priority than the ongoing real-timeapplication workload.
I) If the dynamic classloader must perform JIT compilation, assure that the JIT compiler canbe configured to support eager linking and translation, meaning thatall components are fully resolved and translated when the first of theinterdependent modules is loaded, rather than deferring JIT translationuntil the moment each code module is first executed. Some systems needto dynamically load components which were themselves ahead-of-timecompiled. Verify this capability is supported if relevant to yourproject requirements.
J) Assure that the virtualmachine includes necessary development tools, including symbolicdebugging of both interpreted and compiled code and run-timeperformance and memory usage profiling.
K) Assure that the virtualmachine includes support for cooperating hard real-time Java componentsif the planned development project may require integration withcooperating hard real-time components.
To read Part 1, go to
Next in Part 3: Hard Real-Time Java Development Guidelines
Kelvin Nilsen, Ph.D.is chief technology officer at AonixNorth America.
 Guidelines for ScalableJava Development of Real-Time Systems, available at