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?
3
There are two additional items I can remember off-hand:
- JIT compilation
- 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.
4
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.
11
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)