JRuby 1.6.5 Released

Implementation choices have costs and benefits. One cost of the original MRI (Matz Ruby Interpreter) is that it used "green threads" that could only be scheduled within the process (running on a single CPU) and not across CPUs. Another is that it was written in C, and some of C's semantics and implementation choices bubbled up into artifice that the Ruby user needs to know and care about. As well, the performance of MRI, due to some early design choices, has some limitations.

An implementation of Ruby on a new platform, JVM in this case, allows new choices to be made, involves a different set of tradeoffs, etc. RAM usage, startup time, JIT features, etc -- these are all factors.

JRuby doesn't have a GVL (Global VM Lock, equivalent of Python's GIL), so you can actually get wild with multithreading. :)

There are a few reasons one might choose to use JRuby.

The most frequently cited reason is to take advantage of JRuby's generally quite excellent Java interoperability. In many cases it may be the best way to introduce Ruby into an organization with a large, legacy Java codebase. Further, despite its oft-maligned reputation, Java still offers the largest number of high-quality, performant FOSS libraries of any platform. In our case, we are developing a Rails application along with a supporting Scala library simultaneously. In my experience, JRuby/Java/Scala integration is largely painless.

Further, JRuby could legitimately be considered the best Ruby implementation. It's very rare to find pure Ruby code that works on any other Ruby implementation but not JRuby. JRuby is, in general, faster than Ruby 1.9 (and in almost all cases much faster than 1.8). Further, upcoming enhancements in JDK 7 may allow some very impressive speed-ups (see http://blog.headius.com/2011/08/jruby-and-java-7-what-to-exp...).

Inter-operating between processes is difficult and may be inefficient. That's why languages try to call each other's libraries within the same process.

By embedding Ruby or Python within the Java Virtual Machine or the .NET CLR you start your program/library with a single process.

For instance, Ruby by default didn't have great concurrency so users ended up spawning more processes to handle amongst other things concurrency. JRuby's selling point is that you don't have to work with so many processes and you can instead rely on the battle-tested multithreading of the JVM. It opens up the chance for more bugs when using threads, but you do cut on the need to use so many processes.

Besides, scripting languages have always made it easier to string together a program for testing, managing and prototyping. Not only do you not need to spend time recompiling programs in scripting languages, but you also have more freedom regarding your code. Java for instance demands one class per file. With a scripting language, you can have as many as you want. With a scripting language you don't need a Makefile as it's easier to use just a few files to get your job done.

Now you could question the need to have so many different scripting languages. But you could also question the need to have so many different non-scripting languages as well.

Because your company might have a JVM-only ecosystem but you want to write and deploy Ruby within that ecosystem. JRuby is a great way to bring Ruby into such enterprises.

Not only that, but JRuby tends to be faster than the de facto official Ruby implementation under most high concurrency or long running process conditions.