On other hand, on truly constrained embedded systems where real time is essential, no GC-based language has any business, no matter how GC is good. Even C++ is sometimes avoided.
http://www.pr.com/press-release/136232
Or do you prefer Aegis battleship Weapons System ?
http://dl.acm.org/citation.cfm?id=2402699
These are my favorite examples for Java being used in life critical situations.
> The applications use a combination of Thales proprietary middleware written in C combined with Java code enabled by the Java™ Native Interface (JNI).
> AONIX has additionally delivered professional services to help PERC Ultra users at Thales optimize their applications and improve execution performance including, a customer-specific training course handled the needs of coding in Java™ with hard real time constraints.
Seems like with helping of C and Consulting on 'How to do Java right' they made it work.
> End-to-end distributed thread timing constraints measured from stimulus to response are typically under 100 ms.
Since it is slightly faster than typical (per char) typing speed on keyboard. It appears nice but terribly impressive real time Java use case.
Not Java, not even close. JavaCard is an extremely stripped-down version of Java. I've used it and it feels like C.
From https://en.wikipedia.org/wiki/Java_Card#Java_Card_vs._Java:
> However, many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads). Further, some common features of Java are not provided at runtime by many actual smart cards (in particular type int, which is the default type of a Java expression; and garbage collection of objects).
[EDIT] But I am not arguing with the overarching argument that Java proper can run efficiently on very constrained devices. It all depends on the implementation.