That first article is proving my point. RCE issues only happen in Java in code that unsafely uses specific APIs. In C/C++, a mistake in a basic for loop that writes values into an array can cause a RCE vulnerability. Any pointer being passed around and written to can cause a RCE vulnerability if it might possibly refer to already freed memory. It's often impossible to tell if a bit of code is safe by looking at it directly, and instead it requires a more holistic understanding of the program. In almost every other language, you can be reasonably confident a bit of code is safe if it doesn't use any code loading, deserialization, or unchecked memory manipulating APIs. The few parts that do use those kinds of APIs stand out and can be reviewed more easily.

>https://heimdalsecurity.com/blog/java-biggest-security-hole-...

I'm specifically talking about the rate and severity of bugs in non-malicious code. Java's sandboxing and plugin aspects were horribly flawed and were rightly put out to pasture.

>Bug enabled RCE can't happen anywhere in a C codebase. It's comparatively rare, too, to other classes of bugs, and depends on how much an attacker can control the input.

It's definitely not rare compared to the rate of RCE bugs in other languages. I'd be surprised if most C/C++ programmers who have written their own non-trivial programs haven't written at least one memory-mishandling bug that allowed RCE. I really don't think the fraction of Java programmers who have ever mis-used JNI or deserialization is nearly that high.