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?

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-logicJun 24 '13 at 8:20

@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-logicJun 24 '13 at 12:34

3 Answers
3

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.

Another issue, albeit small in comparision, is that a class is only loaded when it is going to be used.
–
T-BullJun 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-logicJun 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

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)