Linked by Thom Holwerda on Mon 16th Apr 2007 20:56 UTC, submitted by BlueVoodoo
Java "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."
Order by: Score:
Not the first word that comes to mind...
by jasutton on Tue 17th Apr 2007 03:34 UTC
jasutton
Member since:
2006-03-28

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")?

Reply Score: 2

Soulbender Member since:
2005-08-18

"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.

Reply Score: 3

Laurence Member since:
2007-03-26

"

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

Reply Score: 2

taos Member since:
2005-11-16

"must not be delayed" != "must not be slow"
What you quoted reinforces "Real-time != Speed".

RT is all about _predicable_ timing, not raw speed.

Reply Score: 2

Laurence Member since:
2007-03-26

"

"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

Reply Score: 2

Matzon Member since:
2005-07-06

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.

Reply Score: 1

Laurence Member since:
2007-03-26

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 :-)

Reply Score: 1

sbergman27 Member since:
2005-07-24

"""
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

Reply Score: 3

Linux
by Andre4s on Tue 17th Apr 2007 06:44 UTC
Andre4s
Member since:
2006-02-10

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

Reply Score: 2

The right tool for the job
by gpsnoopy on Tue 17th Apr 2007 09:14 UTC
gpsnoopy
Member since:
2007-04-17

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 ?

Reply Score: 3

RE: The right tool for the job
by ahmetaa on Tue 17th Apr 2007 18:12 UTC in reply to "The right tool for the job"
ahmetaa Member since:
2005-07-06

No you are just ignorant.

Reply Score: 0

What is the advantage of Java over Ada?
by axilmar on Tue 17th Apr 2007 12:19 UTC
axilmar
Member since:
2006-03-20

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.

Reply Score: 1

"Java is slow" people read the article...
by Hank on Tue 17th Apr 2007 13:26 UTC
Hank
Member since:
2006-02-19

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.

Reply Score: 1

some clarifications
by barspi on Tue 17th Apr 2007 13:49 UTC
barspi
Member since:
2007-01-04

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...)

Reply Score: 5

v Java in a airplane
by Southern.Pride on Tue 17th Apr 2007 15:26 UTC
RE: Java in a airplane
by Andre4s on Tue 17th Apr 2007 16:50 UTC in reply to "Java in a airplane"
Andre4s Member since:
2006-02-10

Always as terrible as the programmer!

Reply Score: 0

RTSJ != Java
by bariole on Tue 17th Apr 2007 21:36 UTC
bariole
Member since:
2007-04-17

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

Reply Score: 2

Time Deterministic Library Required.
by dautelle on Wed 18th Apr 2007 00:53 UTC
dautelle
Member since:
2007-04-18

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

Reply Score: 1