Well it all depends how 'hard' your real-time is. If you go with Atego/aonix, you can get down to almost-C-Ada-like latencies but be ready to change your java coding style. Sliced-time GC works OK until you put too much pressure on it (concatenating logging strings that you're not going to record or display... allocating tons of small objets for local uses... Programming in 'Classic' java...) and it can't clean up fast enough... In the end you code in a small and sad watered down subset of java... I mean : java is everything (almost, except for primitive types) on the heap ! Avoid java collections (use javolution or hppc-rt instead), avoid auto-boxing, no local allocation, no String concatenation, no Selector API ('select' in java nio...) because it allocates like mad... God help you if you need to stream some amount of data via TCP. And be prepared to spend some time to fine tune the GC. You also take a hit on performance and compilation time compared to hotspot (you need aot compilation for real-time, the java runtime seems not as optimised... Not as many man-decades of work on it).
All in all I'd rank it 'easier' than C in developer comfort and proficiency but frankly, if you don't do C, I'd just go directly to Ada...
I would just argue that un these domains 'Classical C' isn't used, given the constraints regarding language features, using stuff like MISRA-C and similar.
Fully agree with Ada comment, even better if using SPARK.
In any case, many military seem more focused on being easy to hire recruits that already know how to program than training them, hence the ramping up of Java adoption.
Well the argument seems to be that it's easier to hire 'experienced' java developers (hear: have 'java' on their resume...). But the people you get are for the most part either inexperienced (fresh out of school) or you have to break all their classic-java muscle memory. Not sure about the tradeoff here, when you compare training in Ada/SPARK.
You're right about Misra C. Even with Ada you'll end up banning dynamic memory allocation and some stack-exploding stuff, but you still have alternatives like storage pools ('looks-like-dynamic' memory allocation) and Controlled types, and at least you get a stack for structured data types and not just for primitive types...
It's called real-time, garbage collection. It occurs predictably on regular intervals before enough leaks happen to blow missiles up or whatever other tragedy. Aonix and some other vendors have had it for a long time now. Meanwhile, mainstream found out in the past, few years that Go could achieve "low-latency" garbage collection. The field can do more than many of them think given the countless person-years invested in so much GC research and product development. I can't even track all of the GC's especially once they started using genetic algorithms and such to automatically make them.
EDIT to add: It says "Ada" and "Rational." That's an Ada forum. That language has little protection for temporal safety in the 1990's. More than many but not at Rust level or full leak prevention.
Good point :)
I probably should have stuck to picking on Java. Ada is a pretty good example of a language that handles real time use cases with concurrency and memory pools well. That said, it's fallen out of favor in "recent" years.
I've never heard of "real time Java" before—is it soft real-time, like Erlang; or hard real-time, like QNX? What are the concurrency primitives? (Threads? Actors?)
Each of them is a company making serious money in embedded systems. A few do safety-critical. I'll let you wonder whether they were in their right mind for building Java apps and using Java runtimes that don't seem to fail in high-stakes circumstances.
- Oberon, http://www.astrobe.com/default.htm
- Java, http://www.microej.com/resources/supported-platforms/
- Pascal and Basic, https://www.mikroe.com/stm32/
- Ada, http://blog.adacore.com/tag/STM32