What's Next for JRuby? 1.9 Compatibility, Windows Love, and More!
At Rubyconf last week I had a chance to sit down with Thomas Enebo and Charles Nutter from the JRuby team. We talked about the current state of the project, what users have to look forward to in the next release, and a number of other questions regarding integration, deployment and tooling.
DDJ: JRuby became MRI 1.8.7 compatible during the 1.4 release. What's the ETA for 1.9.2 compatibility?
Tom: That's been promised to be the second week of December. I don't know if you're aware of this, but JRuby runs in a 1.8 and a 1.9 mode right now; just specify --1.9 and we behave like 1.9. So we're probably 85% done and the last 15% won't be 80% of the work. We kind of have a handle on what's left and we think we'll have it for [JRuby] 1.6 in mid-December.
DDJ: So that's the general thrust of the 1.6 release then, Ruby 1.9 compatibility? What else is coming in that release?
Charlie: Well in 1.6 we're also shipping support for installing Maven artifacts as if they were regular Ruby gems. So you can gem install a Maven artifact and use it as a dependency, whatever, and it pulls it from Maven.
Tom: Windows support is going to be quite a bit better. We actually plan on dogfooding it ourselves.
DDJ: You're moving to a Windows development environment?
Tom: For a few weeks. Our Windows support I believe is better than the C implementation right now but we realize that it's the platform we don't give enough love. We know there are a lot of people on Windows who want to use Ruby, so we're going to give it a little extra attention [...] to iron out a few wrinkles that we know are still there. And we're also going to support Win32 OLE libraries so we can do OLE automation.
DDJ: So Windows support was also one of the major thrusts of the 1.5 release as well. Can you talk a little bit about what that entailed?
Charlie: It started with 1.4, [where] we spent a certain amount of time fixing things that were problems on Windows. We included a Windows installer for the first time and it was an amazing eye-opener for us. The number of downloads for the Windows installer exceeded all the artifacts that we had ever shipped. It's obvious once you think about it: 80% of the world still uses Windows which means that a substantial portion of developers use Windows. And that's why, since then, we've been trying to support Windows better and better and fix things that the C implementation has never bothered with.
Tom: There are also a lot of Java developers that want to kick the tires and play with JRuby. What machine are they most likely going to be using at work?
DDJ: I understand that JRuby now integrates with Ant. Although Ant and Rake are often used for the same sort of tasks, there are certainly things that one does better than the other (Rake lacks support for some of the standard cross-platform tasks that Ant has, leading to users shelling out to complete tasks, Ant is syntactically icky but also much less flexible than Rake since Rake gives full access to the Ruby interpreter). Do you picture Ant and Rake living side by side in a typical project?
Tom: I think it really depends on the user and their environment. If you're an existing Java shop and you have 50 thousand lines of XML, those people are probably never going to get rid of those files. But what they might be able to do -- and I've experienced this first-hand -- I start to realize that I've started to write imperative code in XML. That's a natural place where you might want to use Rake, where you have all the imperative goodness of Ruby.
I think we really just want to reduce barriers, so that whatever environment you have, there's something that might be appealing for that environment versus opinionated software that mandates that you have to use Rake and that's it.
DDJ: What's the most common approach for deploying Rails or other Rack-based web application on JRuby at the moment?
Charlie: The traditional approach is probably what most Rubyists are going to want to use; they're not going to want to learn how to spin up Java app servers and administer all of that. So we'll continue to support those and keep the command line servers running well. But the truth is that the vast majority of people who are going to deploy JRuby apps are likely to use the WAR file stuff, so Nick [Sieger] has continued to improve Warbler with each release. There's lots of cool stuff in 1.3. We'll continue to support both [deployment options] but there's probably a larger opportunity for JRuby on the WAR file side.
DDJ: So demographically, are most folks interested in JRuby representing shops that already have significant Java deployment infrastructure in place? Or are you seeing a lot of brand new greenfield development?
Tom: I would say that there's really three different use cases. One is that they're already legacy Java users but they want to go and take advantage of Rails. But they still have a bunch of Java business logic, and a bunch of existing apps they [need to continue to support]. The second one is a Ruby user who wants to make use of some technology that doesn't exist in the Ruby ecosystem yet, and they know that it exists in the Java world. And the third one seems to be obfuscation -- they want to compile that Ruby code down to something to try to prevent people from looking at their source code.
DDJ: Are you seeing a lot of users taking advantage of JRuby for obfuscation purposes? Like vendors who are taking their proprietary libraries or applications and shipping them on JRuby with obfuscated code?
Charlie: The one everyone would have heard of is GitHub. Their firewall product is basically a WAR file that you can run in your environment and that's actually a JRuby recompiled application.
Tom: Thoughtworks' Mingle also took a different approach, but they picked JRuby for that reason.
Charlie: [obfuscation] certainly makes it easier to feel safer about shipping your application. Maybe even easier than shipping a Java application, because it's almost impossible to decompile it into something useful.
It's a packaged deliverable, no source code in it, all set to go.
DDJ: The JVM is optimized for long-running applications. The downside of that is that startup time for applications often suffers. What's being done about this? How can developers minimize this problem in production?
Charlie: There are ways to improve it. We've posted various walkthroughs about improving the startup time of JRuby. Oracle will have to address it at some point too, because they want JavaFX or other projects to use small client applications, and the startup time is a major problem for them right now. For example in Java 7 they're introducing something called the Tiered Compiler, which basically gives you the same performance as the full-on server version VM but starts up quickly, does a limited compile right away so that it can get moving much more quickly. They're definitely aware of these problems and continue to improve on it with every release.
Tom: They've also added modular class libraries, although that might not make it into Java 7.
DDJ: I understand that Engine Yard has announced commercial support for JRuby applications. I imagine that this benefits not only your customers but also the language itself, as it allows you to apply lessons learned from large production clients to the language features and project roadmap. Can you talk a little about that relationship?
Charlie: The Win32 OLE support that Tom mentioned actually came out of a customer contract. They needed this feature to be implemented in JRuby, and as a result we were able to implement it for them and then ship it as part of JRuby for other users. We have had other clients come in to do one-off benchmarking or troubleshooting, and all of those do feed back into our process.
Tom: Also, just being an open source project gives us a lot of opportunities to get feedback.
DDJ: How big of a barrier is the native gem problem to JRuby? What about FFI (Foreign Function Interface) as an alternative to C extensions? Is this a long-term solution or is exhaustive porting of all native gems to the Java platform the only real option?
Charlie: There are three [options]. One is to port everything or to find an equivalent Java library and wrap it. That's generally the best way because it's going to work cross-platform, it's not going to have all the native library issues, and it'll probably perform better as well. FFI was also added to JRuby. It at least lets you get at the libraries programatically from Ruby without compiling code, without having the C extension API. The final option, which is kind of the last mile, is in JRuby 1.6 we'll ship our current beta support for actually building Ruby C extensions too.
DDJ: Wow, very interesting. I hadn't heard of that before!
Charlie: It was a Ruby Summer of Code project by Tim Felgentreff. He managed to take Wayne Meissner's work (another JRuby committer) and implement enough of the Ruby C API that a large number of extensions just work. It's awesome. I never thought we'd be able to actually do it, so he made a liar out of me.
It's a migration solution. If there's no other way than a C extension, nobody's used FFI, nobody's ported it... it's a stepping stone. It's very limited, because we can't run the extensions concurrently, it limits where and how you can deploy it [...] but if that's the one thing that's keeping someone from trying JRuby it's an option.
DDJ: I saw Daniel Jackoway's Ruboto talk [at Rubyconf] and came away very excited. This seems like a huge opportunity for JRuby, and for Ruby in general, to be able to develop and deploy applications using Ruby on Android mobile devices. Can you tell us a little bit more about the status of that project?
Charlie: There are folks who've started playing with commercial production applications that they're going to ship for Android with Ruboto stuff, but it's a little early still to be honest. [...] The tooling isn't all there yet, the API wrappers aren't complete yet, and the build process can be improved. It's probably in an early beta state or late alpha quality, as far as the tooling we have right now. It's just going to continue to improve from this point. There are a lot of people interested in seeing it work, so I think it's going to go fast.
DDJ: If there was one place inside the JRuby ecosystem where you could say you guys need help right now -- where the community could really help you out -- where would that be?
Tom: I think it's Windows. It's not because the support is necessarily bad, it's more that we want people day to day firing up JRuby in our actual master development tree [and getting us feedback].
Charlie: Talk to your local user group, submit JRuby talks to conferences.
Tom: I wouldn't say we're bad at "selling" JRuby at conferences, but nothing beats someone who's actually using JRuby selling it to an audience.
DDJ: The best salesman is always a customer, right?
Charlie: Those make some of the most compelling talks we've seen, too.
Thanks to both Charlie and Tom for their time and hard work on such a great project. The preceding interview was transcribed from an audio recording of the conversation we had on November 11th and has been lightly edited for brevity. I should note that we also talked a fair bit about the Mirah language (which I'm personally very excited about) -- I'm sure I'll be writing more about Mirah in a future post. Stay tuned!At Rubyconf last week I had a chance to sit down with Thomas Enebo and Charles Nutter from the JRuby team. We talked about the current status of the project, what users have to look forward to in the next release, and a number of other questions regarding integration, deployment and tooling.