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.
views:
408answers:
7There are a number of reasons:
- History - the airline system is older than Java. It might need a rewrite, but it's not in progress today that I know of.
- 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.).
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.
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:
There is really not much stopping you from using java for real-time systems. There are two different approaches.
- 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.
- 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.
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.