Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Go Inside the Java Real-Time System

Real-time Java is about more than applications that need to be fast. Find out what real-time requirements actually are and get an in-depth look at what Sun Microsystem's real-time Java can do for you.




Application Security Testing: An Integral Part of DevOps

he Sun Java Real-Time System (Java RTS) is the first conformant commercial implementation of Java Specification Request (JSR) -001, the Real-Time Specification for Java (RTSJ). Although initially released in 2002, the RTSJ was updated in July 2006 to include some new features which are covered in this article.

Java RTS enables developers of real-time applications to take full advantage of Java while maintaining the predictability of current real-time development platforms, such as QNX, and other, custom, embedded systems. With Java RTS, real-time components and non-real-time components can coexist and share data on a single system. 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, giving developers heretofore unforeseen flexibility. Sun offers an RTSJ-compliant Java VM that runs only on Solaris (both x86 and SPARC); whereas IBM offers one that runs on Linux with open-source real-time Linux extensions.

This article will demonstrate the advantages of Java RTS over the standard Java VM, as well as over C++, for applications that have soft and hard real-time requirements. To do this I've created a sample application that simulates a temperature control system that must react to real-world events (i.e. temperature change) to maintain an ideal operating temperature for a critical application, such as a nuclear power plant.

In this simulation, if the temperature control system is used in a nuclear power plant or for a ship's engines, the result of an unforeseen delay in processing (i.e. from the garbage collector) can have dire consequences. Before I get into the specifics of the simulation application, I think it's important to first discuss the concept of real time.

What is Real Time?
In computer science, real-time computing (RTC) is the study of hardware and software systems that are subject to a real-time constraint, such as operational deadlines for event-to-system response. Compare this to non-real-time software systems that do not have such deadlines, even if the goal is to perform quickly. Real time is often confused with "real fast." In fact, quick performance is not necessarily a requirement in some real-time systems. For instance, a financial institution may need to perform settlement processing once a day at a certain time; hardly a high-performance requirement. Instead, real time is all about building systems that have deterministic behavior, with predictable, guaranteed, response times. Whether your software needs to check for an event once every millisecond, or once a day, it must do so predictably, without unforeseen delays, interruptions, or latency.

There are two basic types of real-time systems: hard and soft. A hard real-time system will experience a critical failure if time constraints are violated, whereas soft real-time systems tend to be flexible. A hard real-time system requires that its operations be performed correctly, and within their time constraints, to be considered successful. An operation performed after its deadline is strictly considered incorrect and of no value to the system. An example of a hard real-time system is an elevator, where the software must react to an event (such as a floor sensor) in order to behave properly (stop at the desired floor).

In soft real-time systems, some latency is acceptable, but overall system predictability is still mandatory. An example of a soft real-time system is a stock trading system used by professional traders. In this system, it may be a requirement for certain positions to be bought or sold when market events occur. A certain amount of system latency may be acceptable, but the event must still be reacted to within a deterministic period of time. To summarize, hard real-time systems require immediate system response, and soft real-time systems can withstand some bounded latency.

Real-Time Java
Often, real-time application developers will rely upon facilities within a real-time operating system, programming language, software framework, or a combination of all three, in order to achieve real-time behavior in their applications. Examples of such environments are QNX, VxWorks, Nucleus, and Solaris; each environment typically comes with tools and libraries for real-time application development.

Historically, Java has been discounted as a real-time language. This is due to the initial impression of Java being slow in its early years. Besides the fact that real-time behavior is not necessarily dependant on high performance, Java has come a long way in terms of raw performance. With just-in-time (JIT) compilation, coupled with the Sun HotSpot JVM, Java performance meets or exceeds that of similar applications written in C/C++.

Sun's Java RTS is a separate implementation of Java that meets both soft and hard real-time requirements and requires a special JVM to run. However, Java RTS still maintains complete compatibility with existing Java SE 5 applications. In fact, it can run standard Java SE applications in the same JVM alongside applications developed to use its real-time facilities. Tests have shown that Sun's Java RTS achieves maximum latencies of 15 microseconds, with around 5 microseconds of jitter. Yes, that’s microseconds, not milliseconds!

Currently, version 2 of Java RTS from Sun Microsystems only runs on Solaris 10, both x86 and SPARC versions. This is mainly because Solaris is a true real-time operating system. Java RTS hooks the OS to take advantage of its real-time support and to ensure that your real-time threads do not suffer from priority inversion. With priority inversion, an OS will temporarily boost the priority of lower priority threads to ensure they get CPU time. With Java RTS and Solaris, this won’t happen, further guaranteeing that your real-time threads will never get interrupted.

Java RTS can be viewed as Java SE with new features that provide real-time benefits. How deep you dive into these features is up to you and your application's requirements. Here is a summary of the additional features of RTS:

  • Java SE 5 compatibility—Allows real-time and standard Java applications to run together.
  • RealtimeThread thread class—Used for soft real-time scheduling, this class uses a real-time garbage collector.
  • NoHeapRealtimeThread thread class—This class is used for hard real-time scheduling and synchronization (does not use the Java heap, and hence does not need the garbage collector).
  • Twenty-eight new levels of strictly enforced priority levels. The highest priority Java RTS thread is truly the highest priority thread in the system and will not be interrupted.
  • ScopedMemory memory model—This application-defined scope contains live objects, but these are destroyed immediately when the application exits the scope. Scopes allow your application to control precisely when objects are created and destroyed without garbage collection.
  • ImmortalMemory memory model—Objects created here are not destroyed until the application exits. You need to be careful what gets created here or you will run out of memory.
  • Asynchronous event handlers—These handle external events and allow you to schedule your application’s response without spoiling the temporal integrity of the overall system.
  • Asynchronous transfer of control—This allows you to transfer control from one thread to another or quickly terminate a thread, in a manner that is safe from a real-time perspective.
  • High-resolution timers—These timers have true nanosecond accuracy.
  • Safe direct physical memory access—This allows device driver code to be written in Java without resorting to native code

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date