[Fasebook]

Read this backwards: http://en.wikipedia.org/wiki/Java_EE_version_history

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.

[mavroprovato]

I really do not understand what the Jave EE version history page has to do with the security of the Java runtime.

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 :-)

[berdario]

How can a JRuby (or Clojure, or Jython...) REST api trigger a vulnerability in the Java reflection?

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)

[jerven]

The JVM has at least a security model/system. Something the Ruby MRI VM lacks. i.e. a ruby program is never in a sandbox.

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.