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?

  • 4
    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, 2013 at 8:20
  • 2
    @SK-logic s/incompetent/uninformed/g Jun 24, 2013 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, 2013 at 12:34

3 Answers 3


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.

  • Another issue, albeit small in comparision, is that a class is only loaded when it is going to be used.
    – T-Bull
    Jun 24, 2013 at 7:46
  • 5
    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, 2013 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, 2013 at 16:00
  • @SK-logic - right, good point!
    – aviv
    Jun 24, 2013 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.

  • 13
    @Giorgio: for hard realtime guarantees? Yes. Jun 24, 2013 at 6:10
  • 5
    Additionally, there are available operating systems that are designed for Real Time from the start, e.g. FreeRTOS.
    – shieldfoss
    Jun 24, 2013 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?
    – user7043
    Jun 24, 2013 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, 2013 at 9:09
  • 3
    @delnan - The question has false premices, suggesting that C++ is a real time programming language.
    – mouviciel
    Jun 24, 2013 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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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