Actually they will.
https://www.ptc.com/en/products/developer-tools/perc
https://www.aicas.com/cms/en/JamaicaVM
https://developer.android.com/things/
Just a small overview, as I don't feel like posting all links from everyone active in commercial Java compilers for embedded deployments.
Embedded isn't unaffected by Wirth's law.
In any case, those systems are far from having the physical and technical constraints of the actual system on a missile, plane or satellite; simply put, a 50ms delay to know the speed of a remote object is acceptable, a 50ms delay to know the speed within said object isn't.
To this day, and to the best of my knowledge, 95% of hard realtime logic is C, C++ and Ada or a combination of them, when not custom ASICs and FPGAs for low latency and high throughput tasks.
If we're talking about other systems, I'd like to know about them.
I'm surprised to hear they're using Java though, I figured they would go to C or C++.
Apparently embedded now means PICs with 8 KB, while anything else more powerful than a late 80's Cray is not embedded anymore.
https://www.techbriefs.com/component/content/article/adt/fea...
Your link specifically calls out general purpose computers, not embedded systems. Java is probably not the worst language to use in that particular application, but it's certainly very close to the bottom of the list.
For most embedded devices, this is not true.
When you're paying for every device the code runs on... and that code wastes 80% of your cycles in abstractions and indirections then forces you to have 200% more RAM than the equivalent C code, that changes your mind.
Saving a tiny amount on a processor adds up when the multiplier is (say) 1 million units.
Otherwise anything of ARM Cortex M class does have Java compilers available.
Garmin devices use Monkey, which is their own Java like language.
Ricoh and Xerox copiers use Java on OS stack for third party integration.
Likewise Cisco conference call systems have their own Java flavour.
Blu Ray players, Gemalto intelligent electricity meters, and plenty more of other examples are available.
Less overhead will allow a cheaper device.
Its worth noting that the java support on Cortex-Ms (Jazelle) is deprecated. If you're using a cortex-m class device, chance are you don't want to be running java on it.
Note that I'm talking in general terms, there are always exceptions to the rule (such as for the rare sandboxed application).
There is this little feature of all commercial Java toolchains for embedded development called AOT compilation to native code.
"Monkey C" (name apparently chosen only for the pun) didn't strike me as especially Java-like when I used it, and given the memory constraints placing such a low limit on the practical max size of Garmin watch applications, that it was OO at all seemed more a hindrance than an aid. I kept wishing it was just C, and I'm not even that good at C.
The point being that the choice of language is strongly influenced by the domain the software is developed for.
I graduated 16 years ago and I have always got jobs which were pure C, on state-of-the-art products as well. That's still the way it is, plenty of jobs available.
Not everyone is targeting PICs with 8KB Flash memory.