Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Except the garbage collector, what are some other features in Java that make it unsuitable for real time programming? On the net, whenever Java vs C++ is discussed with regards to real time programming, it is always the garbage collector that is mentioned. Is there anything else?

share|improve this question
2  
Even garbage collection is not an issue - there are several hard real time garbage collectors available. Those who mention gc as a show stopper for real time are simply incompetent. –  SK-logic Jun 24 '13 at 8:20
1  
@SK-logic s/incompetent/uninformed/g –  Scott Whitlock Jun 24 '13 at 12:30
    
@ScottWhitlock, agreed, most of them are. But some (the most vocal) keep insisting even after being properly informed. I'm not aware of any rational explanation for this anthropological phenomenon. –  SK-logic Jun 24 '13 at 12:34

3 Answers 3

up vote 33 down vote accepted

There are two additional items I can remember off-hand:

  1. JIT compilation
  2. Threading implementation

In term of real-time, predictability of performance is probably the most important factor; That's why an unpredictable GC cycle makes Java unsuitable for real-time.

JIT offers improved performances, but kicks in at some point after the program is running, taking some resources, and changing the execution speeds of the system. It can also happen again at a later stage, if the VM believes it can do a "better" job at that time.

As far as threading: I don't quite remember at this point if this is part of the language design, or just a very common implementation, but Java usually provides no tools to precisely control thread execution; For example, while there are 10 "priorities" specified for threads, there's no requirement that the VM actually considers these priorities. Operators for stopping and switching threads are also either not defined, or not rigidly adhered to by the system.

There are several implementations of JSR 1: Real-time Specification for Java - a spec that has been approved in 1998. This spec addresses as much as possible of the issues that makes standard Java unsuitable for real-time.

As of maybe 5 years ago, Sun (Now Oracle) had a RTSJ VM (That never had a name, AFAIK); IBM had WebSphere Real Time; And JamaicaVM was a free(?), platform-independent solution. Googling those today doesn't bring much.

share|improve this answer
    
Another issue, albeit small in comparision, is that a class is only loaded when it is going to be used. –  T-Bull Jun 24 '13 at 7:46
3  
There is nothing in Java specification which will enforce JIT instead of AOT or a pure interpretation. Pure green threads are totally predictable, so they also cannot be a real time obstacle. –  SK-logic Jun 24 '13 at 8:21
    
websphere real time at least still seems to be supported (claims Java 7.0 support and you can get to a page to purchase it) –  jk. Jun 24 '13 at 16:00
    
@SK-logic - right, good point! –  aviv Jun 24 '13 at 17:04

The operating system

As long as Java runs on top of Unix or Windows or any other "regular" OS, realtime is not guaranteed.

A real time OS is mandatory for running realtime applications.

share|improve this answer
12  
@Giorgio: for hard realtime guarantees? Yes. –  Joachim Sauer Jun 24 '13 at 6:10
4  
Additionally, there are available operating systems that are designed for Real Time from the start, e.g. FreeRTOS. –  medivh Jun 24 '13 at 7:33
4  
While this is a very important point for hard real time in general, it doesn't appear to be Java specific in the slightest. Am I missing something? –  delnan Jun 24 '13 at 9:04
3  
@delnan the point is, even if you use a (imaginary?) real time implementation of a Java VM it doesn't help much if the OS can't give you real time guarantees. –  schlingel Jun 24 '13 at 9:09
3  
@delnan - The question has false premices, suggesting that C++ is a real time programming language. –  mouviciel Jun 24 '13 at 14:10

Technically it's possible to have real time java (as SK-logic's comments suggest). however it is not common for a number of non-technical reasons:

Old standards

Having trouble finding a reference for this but I'm certain I've seen safety standards, or safety standard conformance advice, put a blanket ban on Java. Rightly or wrongly if you have to conform to something that says Java is verboten then Java is Verboten.

Old safety engineers

Even if the standards you need to work to don't ban Java, working with Safety/Quality auditors without experience of Java will very much mean you are not following the path of least resistance. Anything that is out of the ordinary for the auditor will likely attract a lot of questions which in turn means lots of work for you justifying your choices.

The community

i.e. there is a lot of path dependency, most of the current real time experts will know C++, C or ADA inside out so it is a natural choice to do new work in.

(note: I've somewhat conflated real-time and safety in the above, which is sort of an another issue, in that even safety standards often conflate the two)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.