JRuby is actually a project started about 2001 or 2002, it had been around for several years before I got involved. It was originally just a port of the C Ruby parser, and once you've got a parser you might as well try and create an implementation, so that's how it got started. When I got involved, a friend of mine, Tom Enebo, was the current lead of the project, and I thought it might be interesting to try and learn Ruby and work on JRuby at the same time. That was about 2004, right around RubyConf 2004 I found JRuby and have been working on it since then.
2. What kind of changes have you done with JRuby since you got involved?
Since I got involved we have done a lot of work on performance, we have done a lot of work on compatibility, actually probably compatibility is more of the primary focus that we've had for most of that time. At first just trying to fix as many bugs as we could in various parts of the system, and then later getting a little bit more ambitious and trying to actually run key Ruby applications, like eventually Rails, we managed to get running on JRuby. Once we got to that point we realized we really could do just about everything, make this a full Ruby implementation and we continued on and got other applications working, and other libraries, started making JRuby on Rails actually a choice that people would want to choose, and then hitting performance a lot. We went through a couple of different interpreter implementations, went through a few compiler prototypes and now finally working our way towards a fully complete Ruby compiler for the JVM.
3. You mentioned that Sun got involved with JRuby. Why did Sun make that decision?
In early 2006 we decided to try and actually get real applications running, along with that came Rails, and with Sun interested in what developers are doing, and what developers are excited about, Rails has definitely been on the radar for a while. We heard from a few folks at Sun that it would be very impressive and very interesting if we could get Rails to run on JRuby. So at JavaOne last year we were able to present it working, in a cobbled-together form but it was actually working, and shortly after that we started hearing from Sun about possibly coming onboard to work on JRuby full time. Generally the draw is that this is a platform for running Rails on that can fit into organizations that already have Java applications and Java servers, and obviously Sun wants to try and make developers happy, so finding a good way to fit Rails into those existing systems and existing organizations is a big draw for them.
Right now with JRuby on Rails, which is essentially just Rails running on JRuby, you can take any existing Rails application, package it up as a Java web application and deploy it on all the same servers that you would use normally. It really is just another web application in that model. For companies where you may not have control over production servers or where the production servers are only ever going to run Java, this allows people to bring in a totally new web platform with Rails and deploy it alongside all their existing applications.
Actually there is. There has been an unofficial version that supported JRuby for quite a while, roughly at RubyConf last week, the Mongrel guys finally released an official version of Mongrel, Mongrel 1.1 I think, that has a Gem, Ruby's packaging system, a Gem for JRuby. So you can install it directly on JRuby, it has support for all the same settings and running as a fast Rails web server and it has been working pretty well, there are a number of folks that are actually running with that Gem on various things now.
JRuby has become sort of a pet project for looking at what changes we could make to the VM to better support languages, and there's a lot of those changes. The problem is that there are probably too many changes, more than we would want to include in, say, a future Java 7. This multi-language VM idea, it was also called a kitchen sink VM which is kind of descriptive, this idea of having a VM that maybe isn't official Java, but that we could have all these features in to try them out and see if they help language development, see if they end up pushing the platform in the direction we want it to go. I have been working fairly closely with John Rose and some of the other folks at Sun who are doing this more advanced VM work, feeding them information on what features we could use in the JVM, what are the pain points of trying to implement languages on the JVM and a lot of that is starting to feed back into this process now. Hopefully we will start seeing binaries of a multi-language VM that has a lot of this in it.
The interesting thing about the JVM and specifically Sun's implementation is that since it is open source now we can have a couple of different versions, we can have a couple of friendly forks within or without the company, and be able to try a lot of these different things. I would expect that this would probably be another branch of OpenJDK, it'd be another version of the JVM that's not officially Java, but it's something that we can use to play around with some of these features. And that gives us the opportunity to try them out and let people run with it, run their languages, modify their implementations, and then see which of those features actually make sense to try and include in future versions of the official Java.
Well, probably the biggest one, and it's not really a technical issue, it's more the political side of trying to get Rails into an existing organization. There are so many organizations that run with Java application servers and have mandates that "everything shall run on this Java server", but a lot of folks want to be able to run Rails. And beyond any technical issue just the ability to package up a Rails application as a normal Java web application is probably the largest draw. Now very recently we started to see performance numbers coming out from some of those large applications and some of those production users that the current versions or the newer versions of JRuby actually are faster at running Rails. We are starting to cross that line now where there are a lot of really good technical reasons to run JRuby on Rails as opposed to regular Ruby on Rails too. I guess the last area would be the ability to start pulling in all of the thousands of libraries that exist for the Java platform; being able to use ten different PDF generating libraries or any of the Apache projects, or any of the various Sun projects that give you graphics support and other features. A lot of those things simply don't exist for regular Ruby so by running JRuby on Rails you get that benefit immediately.
9. What do you think is going to be coming up in the future for JRuby?
In the future, we've got our final 1.1 release; it is supposed to come out somewhere in December. The big bullet for that is that we do have a complete Ruby compiler to Java bytecode now, which has substantially helped performance. After the 1.1 release, I would say the big areas are going to be fitting JRuby better into the rest of the platform. The implementation itself will be at some level of done and there is probably not a whole lot of major work that we would need to do to get the Ruby side of things running well. We will continue working on performance, and there will always be compatibility issues, but we will continue to solve those as they come up. But we need to focus on how Ruby fits in as just another JVM language, so that it can call all of the libraries as well as possible, integrate well with other Java frameworks, and really just be a first class citizen on the JVM. That's probably going to be the big thing that comes up after the 1.1 release.
The two major database libraries that Ruby folks use would be probably the Ruby DBI, or Database Interface, and the ActiveRecord library that comes with Rails. We have support for both of those running on top of JDBC, ActiveRecord JDBC being the larger of those two efforts. Basically it allows you to run ActiveRecord with any JDBC database, a few are better supported than others. The other interesting side is what you mentioned, Hibernate, and there is an early project now to do sort of an ActiveHibernate, which has all of the features of Rails ActiveRecord and the same easy to use DSL-like interface, but it's actually using Hibernate behind the scenes. You'd never actually know that from looking at it, it really just ends up looking mostly like a typical ActiveRecord database session, but you get all the features of Hibernate as well.
As a lot of folks that are actually interested in trying to build newer frameworks and newer web frameworks based on things like Spring plus JRuby. You can still have all the other components wired in, and use pretty much any language you want for all those other components, or use the existing Java libraries, but it gives you an opportunity to start mixing and matching these tools a little bit more. There are also a few folks that are looking at doing Spring combined with Rails, so that you can have your JRuby on Rails application plugged in as a Spring service, and then have other services plugged into it that it can use for persistence and for messaging and other stuff. I think more and more folks are going to be taking advantage of the fact that JRuby actually runs on the Java platform with all these existing libraries and creating some interesting hybrid solutions.
For the first time I think we have got a community doing a lot of different implementations of a particular language, and all trying very hard to stay true to the original spirit of the language from when Matsumoto created it. We really want to work with the community and I think they are recognizing that we are trying to be as good a citizen as possible within that Ruby world. We are not trying to make a fork, we are not trying to change Ruby, we are not trying to take Ruby over. We really just want JRuby to be another option for Ruby users. And from all the discussions that I've had with all the other implementers that's their goal as well, they really want to try and help Ruby take over the world, help it be the language of choice on whatever platform you are running. It's been a great time working within that community and seeing how much cooperation there is.