> 4. Who really cares about cross-platform code if all I do is on Linux?
Most developers write their code on Windows and MacOS and then deploy on Linux. I'd say this "Write once run anywhere" thing was and still is a pretty big deal.
> 5. Why does this program require 4GB of ram?
Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind of nonsense is that?
> 6. Must I really download and install the JVM all the time, and what is it good for anyway?
Once or twice a year, if you really want to. You update your browser much more often.
> Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind of nonsense is that?
4 GB per program absolutely destroys VM consolidation. I love the look on managers' faces when they ask for a 1 GB VM and I ask them, "Is this for a Java program?" :)
Imagine, Java is run on your phone's SIM card. Enough?
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.
Well 2 thing stand out for me from links you mentioned:
> 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.
> 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.
The point is that memory still matters, not that Java is inherently a problem. You're shifting the goalpost here - earlier your claim was that 4GB is not a big deal since we can just buy more memory, now it's that 4GB is a ridiculous number anyway.
It's not if you meet one of these typical "don't do any premature optimisations (even in the design phase of my data structures), because some important CS person said so"-designs. There's all too many programmers who think they should never have to care about hardware anymore.
If you looked at the issues and verified they're either not applicable in your case or don't affect your application, you already spent a lot of time on it. If you do install, you should verify your app still works. If not, you already spent time on analysis. The actual installation time is next to nothing compared to everything else around the "new jre came out" event.
What I'm saying is - you should care 7+ times a year. Doesn't matter if you only update twice.
Most developers write their code on Windows and MacOS and then deploy on Linux. I'd say this "Write once run anywhere" thing was and still is a pretty big deal.
> 5. Why does this program require 4GB of ram?
Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind of nonsense is that?
> 6. Must I really download and install the JVM all the time, and what is it good for anyway?
Once or twice a year, if you really want to. You update your browser much more often.