Direct memory access. Java RTS allows direct access to physical memory, making it similar to J2ME. No surprise there: one of the main target platforms of real-time Java is embedded systems. This means that now you can create device drivers written in pure Java. Although memory access is not directly a real-time issue, physical memory access is desirable for many applications. Java RTS defines a new class that allows programmers byte-level access to physical memory, as well as a class that allows the construction of objects in physical memory. One might think that physical memory access is the point where Java gives up its main principles--reliability and safety--and takes a step back towards C, but this isn't the case. Java maintains strong security protections by controlling memory bounds and data contents.

Asynchronous communications. Java RTS provides two forms of asynchronous communication: asynchronous event handling, and asynchronous transfer of control. Asynchronous event handling means the developer can now schedule the response to events coming from outside the JVM. Asynchronous transfer of control provides a carefully controlled way for one thread to interrupt another thread in a safe manner.

High-resolution timing. There are several ways of specifying high-resolution time including absolute and relative time. A nanosecond accuracy is available for time scheduling and measurements.

Memory management. There are two new types of memory areas that help prevent unpredictable delays commonly caused by traditional garbage collectors in real-time applications: immortal memory and scoped memory. Immortal memory holds objects without destroying them, except when the program ends. This means that objects created in immortal memory must be carefully allocated and managed, as with C programs. Scoped memory is used only while a process works within a particular section, or scope, of the program (such as in a method). Objects are automatically destroyed when the process leaves the scope. Neither immortal nor scoped memories are garbage collected, so using them avoids problems of GC interference. The Java RTS also provides limited support for providing memory allocation budgets for threads using memory areas. Maximum memory area consumption and maximum allocation rates for individual real-time threads may be specified when the thread is created.

Real-time threads. As mentioned previously, Java RTS supports two new thread models: real-time threads (javax.realtime.RealtimeThread) and no-heap real-time threads (javax.realtime.NoHeapRealtimeThread). Both thread types cannot be interrupted by garbage collection. These thread classes have 28 levels of priority and, unlike standard Java, their priority is strictly enforced. Real-time threads are synchronized and are not subject to so-called "priority inversion" situations where a lower priority thread has a block on a resource needed by a higher priority thread and thus prevents the higher priority thread from running. Thorough testing has proven that Java RTS completely avoids any priority inversions, which is crucial for mission-critical applications.

Let's take a brief look at how easily a programmer can use the new real-time Java features. We'll consider only the most interesting parts of the new API: threads and memory. For other issues, take a look at real-time Java specification (PDF).

One of the main goals of the specification authors was to keep RTS programming simple, despite real-time problem complexity; that means the operating system must handle as much work as possible, leaving the programmer only the challenging task of real-time application design.

The RealtimeThread class extends java.lang.Thread. It has several constructors, giving the developer an opportunity to tune thread behavior:

public RealtimeThread()
public RealtimeThread(SchedulingParameters scheduling)
public RealtimeThread(SchedulingParameters scheduling,
ReleaseParameters release)

The ReleaseParameters and SchedulingParameters provided to the RealtimeThread constructor (as well as MemoryParameters, used by a non-spec constructor) allow the temporal and processor demands of the thread to be communicated to the system. RealtimeThread implements the Schedulable interface. The key is that Schedulable objects can be placed in memory represented by instances of ImmortalMemory, HeapMemory, ScopedPhysicalMemory, and PhysicalImmortal.

A NoHeapRealtimeThread is a specialized form of RealtimeThread. Because an instance of NoHeapRealtimeThread may immediately preempt any implemented garbage collector, the logic contained in its run() method is never allowed to allocate or reference any object allocated in the heap, or to manipulate the references to objects in the heap. For example, if A and B are objects in immortal memory, B.p is a reference to an object in the heap, and A.p is type-compatible with B.p, then a NoHeapRealtimeThread is not allowed to execute anything like the following:

A.p = B.p;
B.p = null;

Given these restrictions, a NoHeapRealtimeThread object must be placed in a memory area such that thread logic may unexceptionally access instance variables. This is why the constructors of NoHeapRealtimeThread require a reference to ScopedMemory or ImmortalMemory. When the thread is started, all execution occurs in the scope of the given memory area. Thus, all memory allocation performed with the new operator is taken from this given area.

We have already noted some memory-related classes. To be more exact, MemoryArea is the base abstract class of all classes dealing with representation of allocatable memory areas, including the immortal memory area, physical memory, and scoped memory areas. The HeapMemory class is a singleton object that allows logic within other memory areas to allocate objects in the Java heap. This method returns a pointer to the singleton instance of HeapMemory representing the Java heap:

public static HeapMemory instance()

A much more interesting class is ImmortalMemory, which is a memory resource that is shared among all threads. Objects allocated in the immortal memory live until the end of the application and are never subject to garbage collection, although some GC algorithms may require a scan of the immortal memory.

A ScopedMemory area is a connection to a particular region of memory, and is a class dealing with representations of memory spaces that have a limited lifetime.

An instance of RawMemoryAccess models a range of physical memory as a fixed sequence of bytes. A full complement of accessor methods allows the contents of the physical area to be accessed through offsets from the base, interpreted as byte, short, int or long data values, or as arrays of these types. If you need float- or double-type access, you should use the RawMemoryFloatAccess class instead. Whether the offset addresses the high-order or low-order byte depends on the value of the BYTE_ORDER static boolean variable in the RealtimeSystem class. A raw memory area surely cannot contain references to Java objects, because such a capability would be unsafe. The RawMemoryAccess class is instantiated with the following constructor:

It is noteworthy that this constructor declares so many possible exceptions types to be thrown. The type parameter is on Object representing the type of memory required. It is used to define the base address and control the mapping.

Real-time Java offers a much more reliable and predictable scheduling mechanism, memory handling methods, different memory models, a more predictable threading and synchronization model, asynchronous event handling, and high-resolution time handling. It makes predictable execution the first priority in all trade-off decisions, sometimes at the expense of typical general-purpose computing performance measures. This is what real-time means.

This article is only an overview of the new concept and Sun Java implementation; if you are interested in more details, it's a good idea to explore the Resources section below. Real-time Java provides real-time capabilities for applications while still being Java, and this makes it a potential success as the first commercially available real-time language.