Real-time means "the ability to reliably and predictably respond to a real-world event". So "real-time" is more about timing than speed and the ability to program a real-time solution means that developers need the appropriate support from the system in order to reason in a temporal fashion. In a more formal way real-time application development requires an API set and semantics which allow developers to correctly reason about and control the temporal behavior of applications. See below requirements to the real time systems described in :
Real-time requirements Real-time (RT) is a broad term used to describe applications that have real-world timing requirements. For example, a sluggish user interface doesn't satisfy an average user's generic RT requirements. This type of application is often described as a soft RT application. The same requirement might be more explicitly phrased as "the application should not take more than 0.1 seconds to respond to a mouse click." If the requirement isn't met, it's a soft failure: the application can continue, and the user, though unhappy, can still use it. In contrast, applications that must strictly meet real-world timing requirements are typically called hard RT applications. An application controlling the rudder of an airplane, for example, must not be delayed for any reason because the result could be catastrophic. What it means to be an RT application depends in large part on how tolerant the application can be to faults in the form of missed timing requirements.
Another key aspect of RT requirements is response time. It's critical for programmers writing hard or soft RT applications to understand the response-time constraint. The techniques required to meet a hard 1-microsecond response are significantly different from those required to meet a hard 100-millisecond response. In practice, achieving response times below tens of microseconds requires a combination of custom hardware and software, possibly with no (or a very thin) operating-system layer.
Finally, designers of robust RT applications typically need some quantifiable level of deterministic performance characteristics in order to architect an application to meet the response-time requirements. Unpredictable performance effects large enough to impact a system's ability to meet an application's response-time requirements make it difficult and maybe even impossible to architect that application properly. The designers of most RT execution environments devote considerable effort to reducing nondeterministic performance effects to meet the response-time needs of the broadest possible spectrum of RT applications.
2.0 Limitations of standard Java
Standard Java applications running on a general-purpose JVM on a general-purpose operating system can only hope to meet soft RT requirements at the level of hundreds of milliseconds. Several fundamental aspects of the language are responsible: thread management, class loading, Just-in-time (JIT) compiler activity, and garbage collection (GC). Some of these issues can be mitigated by application designers, but only with significant work, see more details in 4 part review of Real-time Java [1-4] and the core limitations are described briefly below.
Standard Java provides no guarantees for thread scheduling or thread priorities. An application that must respond to events in a well-defined time has no way to ensure that another low-priority thread won't get scheduled in front of a high-priority thread. To compensate, a programmer would need to partition an application into a set of applications that the operating system can then run at different priorities. This partitioning would increase the overhead of these events and make communication between the events far more challenging.
A Java-conformant JVM must delay loading a class until it's first referenced by a program. Loading a class can take a variable amount of time depending on the speed of the medium (disk or other) the class is loaded from, the class's size, and the overhead incurred by the class loaders themselves. The delay to load a class can commonly be as high as 10 milliseconds. If tens or hundreds of classes need to be loaded, the loading time itself can cause a significant and possibly unexpected delay. Careful application design can be used to load all classes at application start-up, but this must be done manually because the Java language specification doesn't let the JVM perform this step early.
The benefits of GC to application development -- including pointer safety, leak avoidance, and freeing developers from needing to write custom memory-management tooling -- are well documented. However, GC is another source of frustration for hard RT programmers using the Java language. Garbage collects occur automatically when the Java heap has been exhausted to the point that an allocation request can't be satisfied. The application itself can also trigger a collection.
On the one hand, GC is a great thing for Java programmers. Errors introduced by the need to manage memory explicitly in languages such as C and C++ are some of the most difficult problems to diagnose. Proving the absence of such errors when an application is deployed is also a fundamental challenge. One of the Java programming model's major strengths is that the JVM, not the application, performs memory management, which eliminates this burden for the application programmer.
On the other hand, traditional garbage collectors can introduce long delays at times that are virtually impossible for the application programmer to predict. Delays of several hundred milliseconds are not unusual. The only way to solve this problem at the application level is to prevent GC by creating a set of objects that are reused, thereby ensuring that the Java heap memory is never exhausted. In other words, programmers solve this problem by throwing away the benefits of the managed memory by explicitly managing memory themselves. In practice, this approach generally fails because it prevents programmers from using many of the class libraries provided in the JDK and by other class vendors, which likely create many temporary objects that eventually fill up the heap.
Compilation Compiling Java code to native code introduces a similar problem to class loading. Most modern JVMs initially interpret Java methods and, for only those methods that execute frequently, later compile to native code. Delayed compiling results in fast start-up and reduces the amount of compilation performed during an application's execution. But performing a task with interpreted code and performing it with compiled code can take significantly different amounts of time. For a hard RT application, the inability to predict when the compilation will occur introduces too much non-determinism to make it possible to plan the application's activities effectively. As with class loading, this problem can be mitigated by using the Compiler class to compile methods programmatically at application start-up, but maintaining such a list of methods is tedious and error prone.
3.0 Java Real-Time System
Java RTS is not only the first commercial implementation of RTSJ, it's a very robust implementation. The Sun Java Real-Time System 2.0 (Java RTS) is a substantially enhanced release to Sun's first conformant commercial implementation of the Real-Time Specification for Java (JSR-001)  and following enhancement JSR-282 . Implementations of the RTSJ make standard Java technology more deterministic and enable it to meet rigorous timing requirements for mission-critical real-time applications. 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:
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.
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.
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 written entirely in Java. Previously, Java applications had to link to native code to communicate directly with the hardware.
4.0 Developer tools for Java RTS
A Java RTS NetBeans module is available on the netbeans.org site. The Java RTS NetBeans module is actually a suite of three modules, each of which supports a dedicated set of features :
LocalRTSJStubs: This is a bridge module that encapsulates the necessary data for code editing, completion, build time (jar and javadoc files), and also for deployment and runtime (script files).
MackinacPlatform: This module contains all the additions and changes to the NetBeans platform application framework to support real-time development (new wizards, new project categories, and so forth).
Projects: This module contains the Java RTS project templates and additional code to support the new wizards.
The only difference in the development process of an application with the Java RTS NetBeans module compared to a regular NetBeans 5.0 environment is the cross-platform development, namely the remote deployment and remote execution on a target where the Sun Java Real-Time System has been installed.
Unchanged Features in the NetBeans Module
The basic features in the NetBeans integrated development environment (IDE) remain unchanged. For example, the following features remain identical to a standard Java SE application:
Code editing and completion: While editing the code, in the middle of typing a Java RTS API class or method name, the developer can ask the system to provide a list of names to complete the word being typed. The developer can then choose a possible completion from this list, and the corresponding output from the JavadocTM tool is displayed in HTML format.
Build and runtime process: There is no change in this process compared with the standard Java SE application development.
Additional Features in the NetBeans Module
To support the development of a Java RTS application on a remote target, the following features have been added to the environment:
Creation of a new project category called Java Real-Time project in addition to the standard list. The developer chooses this project in order to develop a Java RTS application.
Cross-platform development features. The Java Platform Manager wizard GUI has been enriched with a new platform category called Real Time Java, which allows the developer to specify remote deployment and execution parameters
Application deployment and execution profiles. The user can record, save, import from the filesystem, and export to the filesystem various remote deployment and execution parameters, for example, the Java RTS remote target on which the application should run.
5.0 Real Time Java Platform: WebSphere
WebSphere Real Time V1.0  is a JRE with a SDK that enables customers to build applications with low-latency, highly predictable response times. It contains a Java Runtime Environment (JRE) with Software Development Kit (SDK) that delivers the following capabilities:
Real-time garbage collection: Greatly simplifies real-time application development using standard Java programming
Real-time Specification for Java: IBM provides a conformant RTSJ Class Library
Ahead-of-Time Compilation: Pre-compile code to achieve better performance than interpreted compilation and more predictable response times than Just-in-Time Compilation
Java Executable support: Improves performance with dynamic class loading
WebSphere Real Time is unique from the standard JRE included with WebSphere Application Server in several significant ways. The key to WebSphere Real Time's difference is in its design to preserve the value of the Java language and platform through "garbage collection" as a central element. It reduces or eliminates the primary source of non-determinism via its one-of-a-kind "Metronome" garbage collection technology.
When using WebSphere Real Time, typical Java applications can expect average garbage collector pauses on the order of less than 1 ms. By preserving garbage collection within the Java programming model, memory management remains transparent to developers, unlike an alternative approach called "scoped memory." Scoped memory can be extremely difficult to use, introducing complexities in programming and forcing developers to determine their memory requirements prior to runtime. Further, by utilizing existing Java Standard Edition 5 class libraries, WebSphere Real Time retains the productivity and reusability aspects, which make Java so attractive.
This solution also employs dynamic class loading through the use of "Java executable" (JXE) jar files for eager, fast, and compatible class loading. Ahead of time (AOT) and JIT compilation can be further used to optimize the execution environment. The JIT may be run on an asynchronous, low-priority thread, preserving processor cycles for application without an active JIT. This reduces the complexity of JIT compilation changing the performance characteristics of the application as it runs.
Figure 1 summarizes the core attributes of IBM WebSphere Real Time.
Figure 1. IBM WebSphere Real Time attributes
And Figure 2 depicts its architecture stack, see more details in [10,11].
Figure 2. WebSphere Real Time architecture
For applications that require even lower latency than provided by the real-time garbage collection, WebSphere Real Time supports the RTSJ. Programmers can use the many standard features including priority-based thread scheduling, high-resolution timers, and asynchronous event handlers.
WebSphere Real Time is comprised of the following components consistent with IBM's standard JRE:
Full support for Java Standard Edition (JSE 5.0)
Full support for JCP Real-time Specification for Java 1.0.1
Support for SMP multiprocessor x86 Linux platforms (including IBM BladeCenters)
A well-defined list of JDK classes that are No-Heap Real-Time Thread (NHRT) safe
A core feature of the real-time Java environment is the underlying Open Source real-time operating system. WebSphere Real Time supports an enhanced Linux kernel using system libraries and binaries from Red Hat Enterprise Linux. IBM worked with the Linux community to develop the real-time operating system capabilities needed to obtain required performance for WebSphere Real Time and has subsequently made them available via the open source community.
Previous real-time Linux efforts restricted real-time tasks to a single CPU or a subset of the CPUs on the system, or functioned as a kernel extension with the attendant restrictions in facilities available to kernel code and the lack of security protections of arbitrary code running with kernel privileges. The current approach is to enable all Linux processes to have access to all CPUs on the system.
As was outlined in  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. 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 flavor of Java language. Tooling and platform related support is growing together with the adoption and implementation of Java real-time in mission critical applications across multiple industries.
Real Time Java Part 1: Using the Java language for real-time systems http://www-128.ibm.com/developerworks
Real-time Java, Part 2: Comparing compilation techniques http://www-128.ibm.com/developerworks
Real-time Java, Part 3: Threading and synchronization http://www-128.ibm.com/developerworks
Real-time Java, Part 4: Real-time garbage collection http://www-128.ibm.com/developerworks
JSR-000001 Real-time Specification for Java http://jcp.org/aboutJava/communityprocess/first/jsr001/index.html
JSR 282: RTSJ version 1.1 http://jcp.org/en/jsr/detail?id=282
Java SE Real Time http://java.sun.com/javase/technologies/realtime/index.jsp
Java RTS NetBeans Module 1.0 Getting Started Guide http://www.netbeans.org/kb/articles/java-rts.html
WebSphere Real Time http://www-306.ibm.com/software/webservers/realtime/
Michael S. Fulton, Darren V. Hart and Gregory A. Porpora IBM WebSphere Real Time: Providing predictable performance
Michael Dawson, Mike Fulton, Greg Porpora, Ryan Sciampacone, Mark Stoodley, and Vernon Mauery Creating predictable-performance Java applications in real time
Peter Mikhalenko Real-Time Java: An Introduction http://www.onjava.com/pub/a/onjava/2006/05/10/real-time-java-introduction.htm