tags:

views:

408

answers:

7

why c is preferred instead of java in most of the real time appliaciotn. for example like air line system. i want the some of the reasons except that java is little slow.

+8  A: 

There are a number of reasons:

  1. History - the airline system is older than Java. It might need a rewrite, but it's not in progress today that I know of.
  2. Real time generally steers clear of garbage collection, because you can't have the system waiting at a delicate juncture for the GC thread to finish its work. Things have to be more deterministic in real time control situations. This would be true of Java, C#, and any other language that uses GC.

There is a real time version of Java, but I don't know how widely it's used.

I'm not sure that the conclusion of C/C++ always being faster than Java is still true for JDK 6. A lot has changed since the 1.0 version when a lot of the benchmarks were performed (e.g., faster object creation, new memory model, new generational GC algorithms, revised reflection, etc.).

duffymo
For Java speed comes at the expense of memory.... LOTS of memory...
Thorbjørn Ravn Andersen
True just for Java, or all object-oriented languages? Is there something that Java is doing that C# and others are not?
duffymo
duffy, object-oriented is just a programming model; models don't use memory.
GMan
The languages that implement them might. I'm asking if it's a universal truth. I think all modern languages would be considered memory hogs by older standards, simply because they can. Applications are expanding to fill the RAM vacuum, Java or no.
duffymo
No, programmers fill memory, not programs or languages. The working set of a program can be made arbitrarily small, given enough manhours.
Hans Passant
@Thorbjorn - everything uses LOTS of memory these days :-)
Stephen C
+7  A: 

It's not about slowness at all here. It's about determinism and safety. Java, while normally fast, can hang for a microsecond when garbage collector decides to run and halt the execution for a second. If garbage collector ran while expanding airplane gear just before touching down at 150mph, bad things could happen.

C with explicit memory allocation is much more deterministic and programmer has full control over when exactly and how much memory is freed/allocated and can decide not to free memory while performing safety critical operation.

Currently new critical systems are written not even in C, but in safer languages, like ADA. Which is just as deterministic as C and (from type safety point of view) much safer even than Java.

Marcin
"If garbage collector ran while expanding airplane gear just before touching down at 150mph ... " - No pilot flies a plane like that. You confirm that the landing gear is down and locked *before* committing to a landing.
Stephen C
@Stephen - I'm not a pilot, so I didn't know that. I just needed a simple and colorful example, so I made it up. That said, I believe there are lots of toys around ILS that are timing critical and if they didn't work out because of GC, results would be fatal.
Marcin
+3  A: 

One of the biggest reasons is that C does not have garbage collection. Garbage Collection is great because you don't have to worry deallocating memory and memory leaks are less of a problem, but it may take 100 ms or more to do the garbage collection. In many applications this time is insignificant, but this means that your app can't do anything else during that 100 ms. In certain real time applications this is unacceptable. For more information read this:

http://java.sun.com/javase/technologies/realtime/faq.jsp#2

Jay Askren
+1  A: 
Hamish Grubijan
Sun has a Real Time version of Java - http://java.sun.com/javase/technologies/realtime/index.jsp
Thorbjørn Ravn Andersen
What about the OS requirements? Why i everyone forgetting that the operating system can also screw up timing big time?
Hamish Grubijan
One of the requirements for the Real time version of java is a Real time operating system. See http://java.sun.com/javase/technologies/realtime/index.jsp#requirements
Thorbjørn Ravn Andersen
+1  A: 

There is really not much stopping you from using java for real-time systems. There are two different approaches.

  1. The RT Java from Sun (JSR-1) which basically gives you a new set of APIs to interact with a RTOS and to do memory management yourself.
  2. close to realtime JVMs like JRockit Realtime with a real time GC which takes a way the unpredictable nature of a gc where you might have a 1ms pause at one time but a 10ms pause the next time.

Contrary to what many people thinks, speed is really not what real-time is about. You want a system that is predicable enough to know exactly when things happens (to an extent possible) and to be able to trust that your process takes the same amount of time to complete every time you run it. One thing stopping that with the toolset provided with ordinary java is the built-in set of collections. Javolution is one approach to solve that (and as far as I can remember it is effectively used for airline systems (on the ground)).

At the end of the day, there is however no such thing as a tool that fits everyone. I wouldn't use java for the actual logic of the embedded auto pilot for a lot of reasons but I don't think the real-time aspects are the primary reasons for that feeling.

Fredrik
A: 

Airline systems are written in Cobol, not C.

Thorbjørn Ravn Andersen
Airline systems can be written in almost any language. Many are written in C and also Ada.-1 for COBOL. ;-)
Thomas Matthews
I think he's talking about pneumatics ;-)
James Morris
A: 

C works closer to the machine's hardware. Java runs on JVM. Moreover, C is compiled in On-the-Fly mode whereas java files are compiled first into bytecode files (.class) which are then executed by the JVM.

-In my opinion, the Complexity of coding and performance are the trade-offs on both languages.

Adil Butt
*"Moreover, C is compiled in On-the-Fly mode"*. Incorrect. With very few exceptions, C is compiled to native code and linked before any code is executed. *" ... whereas java files are compiled first into bytecode files (.class) which are then executed by the JVM"*. Again, incorrect. In most modern JVMs, bytecodes are JIT compiled to native code, but some also allow ahead of time compilation to native code.
Stephen C