Java RTS 2.0 Update1 Released

Java RTS 2.0 Update-1 (90 days evaluation copy) is available for download. (Link: Download Java RTS)

The version available on Sun's site is for Solaris (both x86 & SPARC) only. IBM offers another version which runs on Linux with open-source real-time Linux extensions. There is no version available for Windows (with third party real-time extension). This update release provides support for Solaris 10 u4 and J2SE 5.0 u13 libraries as well as various security enhancements.

Java RTS features are delivered via a separate real-time enabled version of the Java VM. This VM can process both traditional Java SE components and Java RTS components. With Java RTS, real-time components and non-real-time components can coexist and share data on a single system.

This release is compliant with Real-Time Specification for Java (RTSJ). In fact, it is the first commercial implementation of RTSJ.

Here is more information on Java RTS (Taken from Sun's Document - as it is)

Here are the important features and benefits offered by the RTSJ and Sun's Java RTS implementation:

• New Real-Time Threads, Scheduling, and Synchronization

  The RTSJ introduces the concept of two new threads: real-time threads and no-heap real-time threads (a thread which cannot be interrupted by garbage collection). These threads offer more precise scheduling than with standard Java threads. They 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. Rigorous testing with partners has shown that Java RTS completely avoids any priority inversions - which is crucial for mission-critical applications.

• New Memory Management Schemes

  The RTSJ defines two new types of memory areas that allow real-time applications to avoid unpredictable delays commonly caused by traditional garbage collectors:

  1. 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.
  2. 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. This is a useful feature akin to garbage collection in that discrete creation and deletion is not required as in the immortal memory case - but the process must be sure to exit the scope to ensure memory is reaped.

  Neither immortal nor scoped memories are garbage collected, so using them avoids problems of GC interference.

• Asynchronous Events Handling & Asynchronous Transfer of Control

  The RTSJ provides two mechanisms for asynchronous communication: asynchronous event handling, and asynchronous transfer of control.

  Asynchronous event handlers deal with external events (known as "happenings") which can occur outside the JVM. The RTSJ is unique in that it allows developers to schedule the response to asynchronous events in order to avoid disrupting the temporal integrity of the rest of the real-time application.

  Asynchronous Transfer of Control (ATC) provides a carefully controlled way for one thread to interrupt another thread in a safe manner.

• Time & Timers

  The RTSJ specifies several ways to specify high-resolution (nanosecond accuracy) time including absolute time and relative time.

• Direct Access to Physical Memory

  While still maintaining security protections, the RTSJ allows direct access to physical memory. This means that device drivers can be created and written entirely in Java. Previously, Java applications had to link to native code to communicate directly with the hardware.

Java RTS Minimum Recommended System Requirements

• Dual core or dual CPU sytem with 512 MB
• Solaris 10 u3 SPARC or x86