It's taking a while to go through all the excellent talk proposals and try to fit in as many as possible into the schedule. In the mean time, I had a quick chat with Charlie Nutter, who will be speaking at the conference. Charlie is co-lead on the JRuby project. [The JRuby homepage is undergoing a revamp over the next week or so. You can find other information on the wiki or the codehaus site.]
MC: Firstly, can you tell us a bit about yourself and your work?
CN: Well, about 5 years ago I went to my first Ruby conference, and liked the language so much I looked up JRuby. When I found that an old friend of mine, Tom Enebo, was leading the project, I started to contribute. At the time I was a "Java EE Architect" but in early 2006 Tom and I and other JRuby community members really started trying to make JRuby solid. Later that year Tom and I joined Sun Microsystems, and I have been working on JRuby ever since. Over the past couple years, I've also tried to be an advocate for JVM languages and Java/JVM improvements that would make language development easier. So I'm a JRuby co-lead on one hand and a JVM languages advocate on the other. It keeps me pretty busy.
MC: I didn't realise JRuby has been going for such a long time! I know its just marked 3 years or running rails, and the 1.3 release is imminent... can you tell us the latest JRuby news?
CN: Latest is subjective; we've had thousands of commits and hundreds of bugs fixed in just the past few months. A few months ago, we released JRuby 1.2, which included more bug fixes and improvements than the previous 3 releases combined. It was also the first JRuby release that started to be convincingly faster at running Rails than "Matz's Ruby Implementation" (MRI). A number of long-standing bugs were fixed, and both memory and performance were a lot better than the previous release.
This week, we've released hopefully the final RC for JRuby 1.3.0, which is mostly a bugfix release. JRuby 1.3.0RC1 was rushed out the door for RailsConf largely to release fixes for Google's AppEngine for Java, which works fine with JRuby. Since RC1, we've had enough additional fixes that it probably was more of a beta, but for RC2 we've actually branched and will release 1.3.0 final next week.
Perhaps the most interesting recent news is that JRuby adoption seems to be accelerating very quickly now. We're seeing job posts, big production site announcements, and I know of at least two announcements coming next week that will further boost JRuby's profile. And we're not standing still...this summer's work on JRuby 1.4 will have a new focus on improving performance (via an improved compiler and upcoming Java 7 features) and improving Java integration (bringing Ruby and Java object models closer together). Expect to hear more about that soon.
MC: Do you find there is a common use for JRuby? Why do developers typically decide to use it?
CN: The majority of JRuby adoption is from Java-based organizations that want to start using Ruby or Rails internally. It's generally too great a political struggle to get MRI introduced into any large existing production setup, and if JRuby supports all the Ruby libraries and code you want to run, you don't have to fight that battle. We hear from banks, telecom, financials, governments, and others that are running sites on JRuby, and every conference we go to we learn about another half-dozen we didn't know about before.
There's also a growing number of folks using JRuby to get better X, where X may be performance, available libraries, memory utilization, multi-core scaling, and so on. While we've always focused on being a compatible Ruby implementation first, we've also tried to give people solid performance, real parallel threads, and access to everything the JVM has to offer. Many people are starting to recognize that and move to JRuby.
MC: "Being a compatible Ruby implementation" must be a bit of a challenge - defining what Ruby is can be quite hard - If you define it as "Whatever Matz says it is", it can still depend on the point release and sometimes the patch level... Can you tell us a bit about RubySpec and how it fits in with your work?
CN: Ruby is, as you probably know, a language without a formal specification. That means we have generally had to cobble together a test kit over the years in order to know whether we're "compatible". Early on, that meant pulling in Rubicon, a set of test cases Dave Thomas wrote when working on the Pickaxe books. Over the years, we've also pulled in MRI's test suite (which is surprisingly small), a test suite called "ruby_test" written by Daniel Berger, a small suite called "BFTS" written by Ryan Davis and Eric Hodel, and finally RubySpec, which I'll come back to. We've also accumulated a very large corpus of our own test cases. JRuby now runs far more tests than any other Ruby implementation, even if you assume there's a lot of duplication.
RubySpec is a project started by the Rubinius team a couple years ago. It's basically an rspec-like set of acceptance tests/specs (I won't debate nomenclature) for all of the Ruby language, core classes, and standard library. It's not complete, but it is of a comparable size to all the other suites we run against JRuby, and much cleaner. Because RubySpec started somewhat after JRuby had surmounted the biggest compatibility hurdles (like running Rails), it has been mostly an additional tool for us to keep improving compatibility. But we fully support and appreciate RubySpec and try to contribute new tests and specs as often as possible.
MC: Another metric you spend a lot of time on is performance and benchmarking. There are many different comparisons of various Ruby implementations (some of which are still 'works in progress'). How would you say JRuby performs compared to other implementations?
CN: We haven't spent as much time on performance as a lot of implementations (especially some newer ones) but I'd say JRuby is at least on par with Ruby 1.9 for running Rails and faster for many smaller tasks. Part of the problem of measuring performance is that it varies so much from application to application. We still get reports of people with Rails apps significantly slower than on MRI while at the same time others report their apps are many times faster. There's no reliable benchmarking suite available for Ruby yet, so we usually have to guess at what the problem might be.
However I will say this: we consider poor performance in JRuby to be a bug...not because we're cocky, but because in almost every case of poor performance it has been something we were doing wrong. So if we can isolate the problem down to a specific piece of code or a specific method, we can usually fix it and often exceed Ruby 1.9 performance at the same time.
Another complex aspect of performance measurement is that most applications depend on code not measured by the microbenchmarks people usually publish. For example, JRuby has scored better on Antonio Cangiano's "shootout" for well over a year, and yet just recently started running Rails faster. Why? Because Rails is not limited by Ruby execution performance as much as by the performance of the core classes. It's easy to get Ruby code to run fast on a given impl, especially early on. But getting all the core classes to perform better is a very slow process, and any one class or method can cripple an entire application.
MC: One last question! If anyone out there wants to help contribute to JRuby, what would you recommend?
CN: We love contributors, and so does our community! The quickest way to get started would be to visit jruby.org, which has links to downloads, howtos, mailing lists, IRC, bug trackers, and articles about JRuby. Installing JRuby is simple: provided you have a Java version installed (1.5 or higher), you just unpack JRuby and it's ready to go. And if you want to help fix bugs, or find a bug you'd like to report, it's easy to check out JRuby from github and build it. All this is detailed in articles on jruby.org, or you can contact us directly via email, mailing lists, or IRC.
MC: Brilliant! Thanks very much for taking time out to chat, it was a real pleasure; and I'll be looking out for those announcements next week!
CN: excellent, thank you!