Ola Bini on JRuby
Today, I attended a tech talk by ThoughtWorks’ Ola Bini on JRuby (JRuby Wikipedia entry here).
I keep hearing great things about JRuby (even Matz has good things to say about it), and it’s nice to hear this from the horse’s mouth as well (Ola is one of the JRuby core developers). Apparently the latest version is highly compatible with Ruby 1.8.6, although applications that use native C extensions are not supported. It’s also impressive how far JRuby has come in terms of performance. Until about a year or so ago, it was still significantly slower than the standard Ruby 1.8 interpreter. Not only have they caught up since then, but the latest JRuby version running on the latest JVM (in server mode) is actually several times faster than the Ruby 1.9 interpreter (aka YARV), which in turn is several times faster than Ruby 1.8 (apparently up to 50x in benchmarks, but more like 1.5x on average). That’s quite an achievement!
The tight integration between JRuby and Java is very impressive. You can explore this by using jirb, JRuby’s version of irb. In this console, you can use all the standard Ruby classes and constructs, as well as Java classes and libraries (Ola demoed this by creating a Swing window and a button, with a listener implemented in Ruby). It really seems quite seamless and powerful.
Due to time constraints, Ola did not talk much about JRuby and Rails (I suppose his JRuby on Rails
Ola mentioned the GlassFish gem as a convenient way to deploy Rails applications using JRuby, although he recommended to mainly use it for development and testing, but not necessarily for production. There are other tools that create a WAR file for a Rails application, which can then be deployed on any standard Java application server. I did not catch the name of the tools that Ola mentioned, but Goldspike appears to be one of them.
About 2 1/2 years ago, I prototyped a scripting engine that ran within the Java based backend for our multiplayer mobile game. At the time, I dismissed JRuby in favor of Groovy and BeanShell (we tried both to see which one we liked better), because JRuby was by far the slowest scripting language to run in Java. Today, there’s no doubt I would have strongly considered using JRuby instead.
It’s weird… somehow Java still feels like a heavyweight system to me, with its compiler, JVM, app servers, etc. But in reality, JRuby is now not only faster than the native Ruby interpreter, but also has a smaller memory footprint. And because it supports proper threads (native Java threads), you should actually have even better opportunities for optimizing the deployment of your Ruby web applications (rather than having to juggle a bunch of Mongrels…)
I will definitely have to take a closer look at JRuby and perhaps try it out with Merb. According to Ola, Merb is supported even though it does use some native C extensions. Sweet!
Update: Ola’s JRuby tech talk is on Youtube now.
February 29th, 2008 at 9:40 am
I too am very excited about the progress of jRuby, if this happened a couple of months ago, our new templating system would have been based in ruby, rather than freemarker.
But then you had to go and bring up Groovy, the slowest slow that ever slowed your slow. I looked at that train wreck and threw it out when I did some tests and showed that freemarker was around 1000x faster.
Go jRuby!
February 29th, 2008 at 11:09 am
Back then, JRuby was an order of magnitude slower than Groovy. Like I said, its performance improvements since then are quite impressive. I’m not a big fan of Groovy myself, and I’m not sure why Sun is still supporting it alongside JRuby. Groovy always seemed like a cheap Ruby knock-off, perhaps slightly more Java-esque. But now, with JRuby being as complete and performant as it is, I really don’t see any reason to use Groovy any more.
March 1st, 2008 at 5:11 pm
I actually got our latest Ruby admin app deployed in Tomcat using Goldspike very easily… I was impressed. The only thing that didn’t work was one of the Date to String replacement tokens wasn’t supported, which I found odd but easy to work around. Can’t speak to the performance, since we don’t care on an internal admin app.
March 1st, 2008 at 7:25 pm
Not bad! Definitely sounds promising (but yes, odd about something basic like date formatting not to be supported in JRuby).
What prompted you to deploy on JRuby / Tomcat vs. regular Ruby, especially if performance wasn’t a concern?
March 3rd, 2008 at 2:20 pm
Actually, date formatting was fine except for one of the replacement tokens (e.g. “%D”, but I don’t remember which one). It was partially an excuse to explore JRuby/app server deployment in anticipation of other upcoming projects that will have the load. But it was also the appeal of ease of deployment, instead of having to worry about managing a bunch of mongrels.
March 3rd, 2008 at 9:36 pm
Ah, makes sense. Well, glad it worked out well for you. I should definitely consider using JRuby for my own Ruby web projects then. It definitely sounds much more appealing than having to micro manage mongrel and nginx, etc.