“This article, the first in a five-part series on real-time Java, describes the key challenges to using the Java language to develop systems that meet real-time performance requirements. It presents a broad overview of what real-time application development means and how runtime systems must be engineered to meet the requirements of real-time applications. The authors introduce an implementation that addresses real-time Java challenges through a combination of standards-based technologies.”
Real-time wouldn’t be the first word I think of when I think Java. In fact, “slow” would be the first word. Now, before I get a bunch of Java developers flaming me for making the same generalization that people have been making for years, I want to point out that it is just the first word that comes to mind for me. I understand that Java has improved immensely over the last several releases, and I applaud Sun for that.
However, even today, Java applications (the first two widely-used apps that come to mind are Eclipse SDK and Azureus) have a hard time keeping up with user interface demands (what the article calls “soft Real Time applications”). So, if that’s the case, why would I want to trust Java with my airplane rudder (an example the article uses to describe a “hard real time application”)?
“Real-time wouldn’t be the first word I think of when I think Java. In fact, “slow” would be the first word.”
Real-time != speed.
“
”
That really depends on the specification of the RT application (ie whether it’s hard-RT or soft-RT)
To quote the article posted:
“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. “
Taking this into account, I think jasutton’s point is more than valid.
Edited 2007-04-17 11:00
“must not be delayed” != “must not be slow”
What you quoted reinforces “Real-time != Speed”.
RT is all about _predicable_ timing, not raw speed.
“
”
Firstly: How are slow response times and delays not the same thing?
Secondly: My quote reinforces that if slow response times affect the core criteria of the RT application then speed is /essential/.
Nobody was saying speed directly defines RT – just that if the criteria of application required less than 0.1 response then the application would have failed its specification. To use their example (again): Predictable timing is all good and well, but if you’re developing an aeroplane rudder control (as per the example) then raw speed in the application is /essential/ regardless of what the umbrella term ‘RT’ covers.
So all of your pedantic arguing about the finites of computing definitions is just avoiding the point the original poster was trying to make: If response times in Java soft RT applications are slow, then where is the confidence that Java is the best solution (given the amount of options available to us these days) for applications which require near-instant hard RT response times?
[edited – messed up the quote]
Edited 2007-04-17 13:00
Firstly: How are slow response times and delays not the same thing? slow response times and delays are fine in an RT system, as long as its predictable
And thats all there is too it. Nothing to do with how fast its running or responding, just that you can predict and guarantee it all.
All you’re doing now is deliberately avoiding answering my question by arguing a slightly different point which I’ve never disagreed with.
I think it’s clear from this that you’re never going to concede that you misunderstood the earlier comments so, by the same token, it’s not worth my time (or anybody else’s) reiterating that point 🙂
“””
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.
“””
Perhaps some descriptions of different kinds of real time applications would help.
If the software operating the controls can miss an event and the result would be that the airplane would only *nearly* crash, or the reactor core would only *nearly* melt down, then that is soft real time.
But if the microprocessor in your convection oven fails to turn the oven off at exactly the right time, and as a result, you totally miss getting grand prize at the bake-off, then that is a hard real time application.
Opinions may differ, depending upon whether one is on the plane or at the bake-off.
Edited 2007-04-17 14:50
Do Linux count as a RT OS now days? I know about some RT patches, but I thought that just added some RT “like” functionality to the kernel.
Edited 2007-04-17 06:47
Use Java for RT development, or how to cut a tree with a toothbrush.
Am I the only one to think that someone insisting on using Java for real-time application is a Java-junkie ?
No you are just ignorant.
Ada has pointers, templates, specifications, ranges, types, subtypes, operator overloading, tasks, user-defined schedulers, etc. These features are way more valuable than anything Java offers for the real-time application developer.
Ada does not have a GUI library, but then it is not needed in a real time system. GUIs for real time systems can be programmed with Java or C++ and communicate with Ada via message passing.
In case you are commenting before reading the article, the posting is about language extensions put into a custom JVM by IBM to allow for real-time operations within Java. They take care of the issues introduced by GC, lack of control over thread timing, relatively poor granularity on the standard timers, et cetera. They did some interesting work with that. No where in the article does it advocate trying to do a hard real time system with a generic JVM.
1) The “Java is slow” myth comes, historically from several sources:
a) Originally the bytecode was all “interpreted”. This has not been the case for years. The first JIT compilers were bad, but after 1.4 they are some of the best in industry/academy. And it has been proven time and time again that for *most* usage cases, the JIT optimizations are much better than what can be done with pre-compiled code.
b) Java is slow to start, yes. And most people’s idea of Java’s slowness comes from applets. Early day applets were specially slow to start up, and modern day applets (the few that exist) appear ridiculously slow when compared to Flash, Ajax, and all the cool Web 2.0 tricks. Now, that slowness in start up time comes frmo a variety of reasons too long to expose here.
c) Finally, the slow GUI. Nobody complained about slow Java GUIs in the AWT days because they were native widgets. UGLY at that, because Sun strived for a common-minimum widget set/look&feel.
Then Swing appeared, suffering from a form of “Patternitis”, added to the performance hit of having to draw *everything* in Java PIXEL-BY-PIXEL, no acceleration, etc. They GUIs now could look great (if the programmer cared enough), and they could look the same in every platform, but.. yes.. slow (not counting the fact of programmer’s inabilities to use Swing efficiently).
This has also been improving a lot. The latest implementations use a lot of hardware acceleration if available, and the IDEs/programmers have finally started to understand the Swing patternitis and best practices… all this may be too little to late for Java desktop GUIs..
2) As some have pointed out here, real time has NOTHING (or very little) to do with raw speed. It has with predictability and system assurance that:
a) certain task won’t take more than xxx time
b) a task scheduled to occur yyy milliseconds from now, won’t start later than yyy + delta, where delta is *guaranteed* by the system. How small your delta is, or how large a delta you want to tolerate depends on your system constraints… could it be measured in (*gasp*) SECONDS?? Well.. maybe yes. Is a delta measured in seconds slow for real time? Maybe NOT!
If you want to capture the trajectory of a subatomic particle that lives 10^-8 seconds, the real time responsiveness of an airplane rudder will seem slow to you.
3) Java gives you a LOT of advantages in many areas of development, that some people are too young/ignorant to appreciate, or too old/stubborn/ignorant to recognize. Would you rather your airplane rudder respond quickly but having bugs and “core dumps” that are almost impossible to track? Would you rather a system full of memory leaks? Until ten years ago, programs were FULL of pointer-related problems, and the systems that are written today (and are expected by the user) are at least an order of magnitude more complex than the software we used to use (and were happy with). And now don’t come and give me examples of today’s kernels written in C and all that… if you know what I’m talking about, you know what I’m talking about (otherwise you are too young/ignorant/old/stubborn 🙂 )
4) I’m tired of writing something that only 3 people will read and forget 10 minutes from now only to repeat the same myths for next week’s article.
(Disclaimer: Airplanes is just an example here taken from the article/comments… I’m not promoting Java usage for airplanes. The air industry has very high standards that can be met in ways idependent of the language/platform used… but still…)
If they ever used Java in an airplane I would never fly again, Java can barely work when coded correctly much less be used in a critical job roll as this.
The core dumps are useless unless you have hours to spend looking at code and never being able to resolve it. The only reason why Java is even used is because of Microsoft if not for the dig at them Java would disappear tomorrow and never be heard of again.
Java is terrible!
Always as terrible as the programmer!
Actually his post was just fine. Point 2 was straight answer to RT programming problem.
In both “versions”, soft and hard, RT programming isn’t concentrated on raw speed but on time constraints and priorities of program segments. In order to do RT programming various mechanisms like run time predictability, transfer of control and preemptive code (from interrupt level to high level programming concepts like threads and process) and stuff like that are needed. And usual pile of languages (C, C++, Java, Python, Pascal, *whatever on common computer*) are not up to that task. All those languages just don’t have those fundamental mechanisms of RT programming. One cannot take his favorite language and compiler and do the RT magic. For many years Ada was only common language designed specifically for RT problems.
This article is not about usual Java which runs Eclipse but about other Java language known as RTSJ which is purposely designed for RT programming as Java is incapable of doing that. RTSJ actually requires special JVM-s in order to run, and between various things has added explicit memory allocation and special interrupt handling. It is actually quite interesting stuff but given your level of ignorance I doubt you’ll ever try to see it for yourself.
Edited 2007-04-17 21:39
The article fails to mention that a RTSJ VM is not enough! You need a time-determistic library such as the open-source Javolution library (http://javolution.org) to take advantage of it.
What the point of having a VM/GC with time predictability to the millisecond if suddenly adding an object to an ArrayList takes dozen of milliseconds due to internal buffer resizing! For an overview of the problem, I would suggest reading the AIAA Space 2005 paper “Validating Java for Safety Critical Applications” at http://javolution.org/doc/Man33955.pdf