Frank Sommers: What are some of the new features in the JRuby 1.0 release?

Nick Sieger: Our main focus for 1.0 was compatibility with the Ruby 1.8 series. We ship with the Ruby 1.8.5 standard libraries. We looked at doing the 1.8.6 libraries as well and, since there is not too much difference between the two, for most applications that should work, too.

The main energy has been focused around test cases. We have one of the biggest Ruby implementation test suites around. We sort of cobbled together a bunch of tests from various projects, and we've been using all those, as well as the test suites of a number of software projects, most notably Rails. Those tests help us define what JRuby compatibility really means.

We have also been working on performance here and there. We feel that performance for 1.0 was good enough that it should be usable for most applications. There are still a few edge cases where JRuby underperforms compared to the C Ruby implementation, but we decided that this will be our stake in the ground, and that we'll continue to work on those issues post 1.0.

Frank Sommers: How compatible is JRuby with the C-based Ruby interpreter?

Nick Sieger: It's hard to put a number on that. We're still up in the mid- to high-ninety percent range in terms of test compatibility. It really comes down to particular applications you want to run.

Much of the force of Ruby adoption is coming from Rails, and we felt it was really important to spend a lot of time ensuring the compatibility for Rails applications. We started to have a lot of success with that around the turn of the year, and have been improving that since then to the point where we can demonstrate Rails running inside a more typical Java stack, running in Java Web containers, such as Tomcat and Glasshfish.

There are still going to be some cases where JRuby is not appropriate, or where it would not be drop-in compatible. Most of those center around light-weight scripting applications, things where you expect to have more of a Unix, POSIX layer available to you that is really hard to emulate with a pure Java application. A prime example of that is the fork system call—there is no equivalent to that in Java. There may be some way to do that in Java, but it was just too big a task to tackle now.

Another area we're not completely compatible with Ruby is in the threading model. We chose to use Java's native threads, instead of implementing green, or user, threading.

In general, we designed the interpreter and the libraries in such a way that you should be able to substitute the ruby command with the jruby command, and run your application. You shouldn't have to do anything special to run your Ruby application. You'll know right away if your application works with JRuby.

The one notable exception is that, in the case of Rails, we use JDBC to connect to the database rather than native drivers—most of the Ruby database drivers are in C code, which we can't duplicate very easily. So we chose to use JDBC. That's one case when you'll have to make some small modifications to your Rails application to run it under JRuby. But we have documentation out there, and there is a growing group of people writing up their experiences as well.

Frank Sommers: What paths can developers with an existing Rails or Ruby application take to try JRuby?

Nick Sieger: There are a couple of different models. You could run JRuby separately, launching the interpreter from the command line and have your Ruby scripts actually load and invoke Java classes. That's one way of doing it. As far as embedding it in an app server, the easiest way may be to use the BSF [Beans Scripting Framework] or the javax.scripting APIs, where you can instantiate the interpreter, and load some scripts into that, and invoke methods or create objects inside the interpreter from Java. We also have a proprietary API for that as well.

This part of the JRuby story is just getting started, by the way. Hopefully, with 1.0, people in the enterprise space will look at this and pick it up and help us really identify what's going to be the easiest way to integrate JRuby into an application.

There is also a Glassfish module for running Rails. With that, you can run a Rails application in Glassfish using JRuby, and you don't have to do anything other than pointing Glassfish to your Rails application—it knows everything else it needs to do from there. That's a quick way to get up and running with Rails. Then there are GoldSpike modules that help you package your Rails application as a WAR file. That's another quick way to get going.

Frank Sommers: What's next for JRuby?

Nick Sieger: We've already been doing a lot of work on NetBeans, and that will continue. Tor Noybe is the developer of the Ruby modules in NetBeans. He recently introduced some refactoring features for Ruby. That's one of the first such things we've seen for a dynamic language, certainly inside a major IDE. We see that as one way to bring JRuby more into the enterprise environment, to have facilities that allow you to use both languages side by side.

In the near-term, the focus of many on the team is to work on performance, to not just remain on par with the native Ruby interpreter, but to exceed it in many cases.

Another area of focus is to shadow some of the development going on on the main Ruby trunk, so that we will be able to support Ruby 2.0 when it comes out. That will ensure that JRuby remains a viable option for the long run.