No, using another language wouldn't have solved the issue. Modifying the code to reduce the amount of garbage produced was one of the solutions. Deleting the code not too long after was the ultimate solution.
This is false. What point are you trying to make here?
of course, Jvm is insecure by design, that's the whole point of a VM, really, to run anything no matter the context, so they're always be the same ways to escape the sandbox: http://seclists.org/fulldisclosure/2013/Jul/172 The only thing keeping it secure is legions of devs and an "application server" propagating trust.
As for the other link, I think you have mixed things up a little. Those vulnerabilities are ways to bypass the Java sandbox, when Java is running in the browser as an applet. This is really not comparable to Ruby, as it cannot run in the browser and does not even have a sandbox functionality as far as I know.
Show me a way to remotely execute code on a machine just because it is running Java, and you will have my fullest attention :-)
I was always under the impression that such kind of vulnerabilities were only a problem for Java applets (where the sandbox is actually important)
Has any exploit ever been built for such circumstances? (I admit that I'm ignorant of their existance)
Using the JVM with JRuby or Ruby MRI as webserver are reasonably equivalent in security footprint. And in recent history MRI has had really worrying security issues too e.g. https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-i...
I mean security can always be improved but you are comparing apples to apples and declaring one of the two to be an orange without decent evidence or support.