Some big clue lines:
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.
As you might guess, using Java for such RT (Real-Time) applications isn’t that obvious. A small summary of the challenges:
– Standard Java provides no guarantees for thread scheduling or thread priorities : It’s quite hard for an application to reacte within a given time if the trhead management doesn’t support this.
– Java-conformant JVM must delay loading a class until it’s first referenced by a program : This causes a delay in the application, and also in the Real-Time response of the applications. As the delay can cause an significant (& possibly unexpected) impact. The same goes for compiling to native code.
– Garbage collection: The GC can cause delays too, and same as the above… and thus cause an impact.
And then some promo on how IBM solves this matter… 😉 Yet it remains interesting reading material if you’re working with Java applications in an environment that depends on performance. It gives you some extra insight on how to tune your machines/code.