Charles Nutter on the JRuby project
In this interview, Kirk Pepperdine of TSS.com interviews Charles Nutter, contributor to the JRuby project. Nutter discusses how JRuby is being integrated into the Java platform and how the JVM is evolving to support dynamic languages. He looks at upcoming support for JRuby in Netbeans 6.0 and addresses broader issues around dynamic languages such as type-checking, scalability and performance.
TSS - Charles can tell us a bit about what you're working on these days?
Charles Nutter - My current responsibilities are primarily completing JRuby, bringing it to a 1.0 release at some point soon, and then trying to go from there taking the information we've gathered, the lessons we've learned during that process and start, or continue working to make the JVM an excellent work environment, an excellent platform for running dynamic languages.
TSS - Your primary focus now is on JRuby then, correct?
Nutter - Yes, that's the primary focus, right now.
TSS - Which brings up an interesting question - Sun has been pushing Java for such a long time. Why would Sun want to embrace Ruby and give it a platform?
Nutter - I think the justification for embracing Ruby and other dynamic and scripting languages is that the rest of the world has for a long time realized, there are many tools, many languages to get work done with. In the typical Unix environment, you have any number of languages all working together. The analogue, the parallel on the Java platform would be using all of those, all of the libraries we're used to, and tying them together with various scripting languages and dynamic languages, like Ruby. So really, people have been moving in this direction and using these languages for years, but [they were] not officially supported on the Java platform. And now, that's starting to change. [We're] starting to recognize that we do have a use for all those other tools, all those other languages, and trying to support them as well, is possible.
TSS - What do you see as being Sun's actions toward other dynamic language projects that are out there that would reflect some of that commitment?
Nutter - Well, I suppose largest, most visible thing is the integration of the scripting APIs in Java 6 and the inclusion of Javascript. Now Javascript obviously is very well supported on the Java platform. So, moving on to helping out another language like JRuby, providing scripting features and adding features and all of the tools, there's more and more of that going on. Trying to be a little pragmatic about it, look at what the most popular languages are; take the best targets for support early on and then take what we learn from them to improve the platform accordingly.
TSS - Is Sun maintaining the open spirit of the Ruby community?
Nutter - Absolutely. They haven't changed any of the licensing or development processes for JRuby. We've also been working very closely with the actual C implementation, maintainers, and trying to stay as much a part of the Ruby community as possible, making sure that we're a good member of that community. And I think that will also continue as we start to try and support more and more languages officially.
TSS - So, there's this good integration into the Ruby community. What about integration back into Sun?
Nutter - For the most part, the Ruby community's been very appreciative and open to the possibility of JRuby being an alternative implementation. We have some interesting ways of solving some of the perceived problems with the Ruby platform, by the nature of having those features already fixed and working on the Java platform. So for folks there, that's an issue -they're interested in the possibility of JRuby. And in that we've tried to be as good a community member as possible. People seem to have recognized we are trying to be a member of the community rather than outside of it.
TSS - I could imagine that after working on your own, on your own time on this open source project and then moving to Sun. You've had to go through some integration processes so that Sun understands what types of support you need internally in order to get things done.
Nutter - Somewhat. It's actually been kind of a surprise. Sun really does understand how open source is supposed to work. And like any large organization that's embracing open source more and more, they've gone through their own growing pains to get to that point. So, projects like JRuby and others that they have started to take in house and started to support officially are sort of teaching them the way that you work with open source communities a little bit more closely. But in general, Sun has been very supportive of this process. They've let us continue to develop JRuby the way we were before, just giving us more time, and Sun experts and engineers as resources to help with the process.
TSS - Have you been able to push information back into Sun from the Ruby process that's actually helped Sun to improve the virtual machine and made it or made it easier for scripting languages in general to run?
Nutter - We've had a number of discussions with the JVM maintainers about what features may be necessary in the future to support dynamic languages. We have talked with a lot of folks considering closures and some other language features about how that fits into a future multilingual platform. We're definitely feeding a lot of the information that we have from developing JRuby, and a lot of the information we've gained from the Ruby community back into the process of improving the Java platform.
TSS - JRuby is really then a second use case for the JVM then.
Nutter - Exactly.
TSS - Did you find that they [Sun engineering] had to implement some changes into the virtual machine already for you or...?
Nutter - Not yet. At this point basically, anything we need that the VM doesn't provide, we build our own library or wrapper to provide that feature. But as we narrow things down and as we make JRuby a tighter and faster and a more efficient implementation, we start to see the places where a VM actually could help or make things more optimal or more efficient. And that's where we start to feed that information back into the process, so that we actually have the narrowest possible use cases for what changes need to go into the VM in the future.
TSS - So that integration process seems to be working very well.
Nutter - Yes.
TSS - Well, you spoke of performance and one of the knocks against Ruby, is that it just doesn't perform well enough for large scale enterprise applications. Is there any truth to that? What is the Ruby community doing to address that, and what are your hopes in terms of performance of JRuby?
Nutter - Well, there's nothing about the Ruby language specifically that should prevent it from performing well or at least as well as any other dynamic language. There are various characteristics of the existing implementations, the C implementations that perhaps make them a little more difficult to optimize because it is a difficult problem to compile or to just-in-time compile or to do any of the more advanced VM features on an existing code base, like the C implementation. We're trying to take some different directions with how we solve those problems in JRuby, and we've started to get a lot of positive performance numbers, managed to improve things, in certain cases passed the existing C implementation. And we are also trying to feed a lot of what we've learned from that research back into the Ruby community so that we can try and be a good member and help them to improve their own performance. And I think the other fact that needs to be noted is that there's a lot of other dynamic languages other than Ruby that perform very well, certainly well enough to write larger applications. And there's no reason we can't apply the same techniques to Ruby. The only thing that's really been missing at this point is a lot of those techniques have not been integrated into Ruby implementations and in some cases we may have to find a new way to integrate them in. But we'll get there and we'll be able to raise Ruby's performance up considerably.
TSS - How do you see adoption patterns for scripting languages like JRuby and in large scale Java shops?
Nutter - Well, we've kind of had a focus on Rails, getting Rails actually up and running, mainly because it provides perhaps the largest use case and test suite that we can confirm Ruby compatibility with. So, since that's one of the first large applications, most of the shops that are looking at JRuby right now are considering running JRuby on Rails alongside their existing Java applications. We are also seeing a lot folks starting to write their own Ruby based DSLs for scripting various Java APIs, and a number of folks who are just starting to write the top layers of their application in Ruby are tying together various libraries directly.
TSS - Does that mean that they have to make a full scale adoption of Ruby? Otherwise, how do Java and Ruby ultimately interact?
Nutter - Well, for most well designed applications the integration points between frameworks and between modules in the system are via fairly well-defined interfaces. And like most of the other dynamic languages on the JVM, JRuby can implement Java interfaces using Ruby code. So you can start to swap out individual pieces of your application by re-implementing them in Ruby and taking the advantages of some of the features of Ruby in that case. There's also frameworks like Spring, and some of the other dependency injection frameworks where you can have the dependency injection framework actually instantiate your Ruby-based or other dynamic language-based implementation of those interfaces, injecting it where necessary. And in that case, your code never has to even know that piece of the system has been swapped out for a dynamic language. It allows you to slowly start migrating more and more of your code to one of those languages.
TSS - Well, speaking of dynamic languages, one of the resistance to adoption of dynamic languages has been the lack of type checking and the fear of runtime exceptions due to type mis-matching..
Nutter - That is always the one that comes up. And oddly enough nobody has actually been able to prove that that is a problem in practice. In fact, it's probably no more a problem in these dynamic languages in real applications than it is in Java. When you look at the most interesting frameworks in applications written in Java, what do they use heavily? They use things like reflection, they use things like code generation at runtime, which ends up having all of the same concerns and the same runtime characteristics that dynamic languages have. So really, it doesn't end up being much of a problem in practice, I don't know what research has been done on this, but for folks actually working with this stuff in the field, it doesn't end up making their applications any less reliable than running with a statically-typed language.
TSS - The other aspect to dynamic languages is difficulty or the perceived difficulty of re-factoring tools and other types of IDE support. Where are you in that regards, and what do you see coming?
Nutter - Well, there seems to have been an explosion of interest in IDEs and refactoring tools for dynamic languages just recently. A lot of it is spurred by the interest in Ruby and the tendency to start using Ruby and Rails for larger and larger applications. As that process continues, there's still a lot of research to be done about how we can do more and more reliable re-factoring, more and more reliable IDE features for these languages and we'll see where we can get with it. A lot of the naysayers tend to say if we can't provide a 100% solution, like we probably can in Java in a lot of cases, then people are not going to want to use it. Well, the truth is, even if you're able to provide a 90% solution that requires a little thought, a little decision making on the developers' part, you're far, far better than you would be than with a glorified editor where you have none of those features to begin with. Usually, the developer's going to know which of multiple choices they need to chose. If it's an ambiguous situation, and by providing that 90%, we'll get a lot farther.
TSS - I'm looking at all this excitement and buzz around JRuby, and I'm saying, I'm interested in learning more and I want to start with the language - how do I start with JRuby?
Nutter - Well, if you go to jruby.org, that will get you links to download the most current versions. There's links to the wiki which has a number of walkthroughs for setting up Rails calling into Java libraries, things like that. There's also a large, growing number of blog posts out there for people doing everything from scripting EJB to implementing Spring components, to writing entire applications entirely in Ruby and pouring them over to JRuby, so that they can just run on the Java platform instead. There's a lot of information out there that's pretty easy to find. And luckily, JRuby is not a particularly common word, so Google searches end up bringing up quite a bit of good stuff pretty quickly.
TSS - I imagine that there's some work that you're doing with the NetBeans Team?
Nutter - Yes, we've not been working on NetBeans directly, because there's a lot of work to be done on JRuby, but we have been supporting them and trying to help them along in understanding both the Ruby language and the JRuby implementation, so that they can do the research and some of the hard work of actually creating those IDE features for Ruby support.
TSS - And how is that work progressing?
Nutter - That work's moving along very well. The Netbeans team has been making tremendous progress, and really only started working on Ruby support in NetBeans in about September. They now have code completion, finding usages and are starting to move into re-factoring features. We're going to see a lot of good things coming up over the next few months.
TSS - Do you expect that to be released with NetBeans 6.0?
Nutter - Generally, this sort of feature is going to be an external plug-in, but available through the update center in NetBeans.
TSS - So, where do you see all of this going within the next three to six months, one year?
Nutter - Well, I think over the next three or six months, we're going to see more and more people using languages like Ruby to do larger and larger application development, more and more emphasis on building the tools out and improving their quality and accuracy, and in the six month to year timeframe, we're going to start looking at what we need to do on the Java platform at the VM and API level to better support these languages and to make sure that they can interoperate well with Java and with each other and carry things on into the future, making the platform as multilingual as possible.
TSS - Is there any other message you have for TSS members?
Nutter - Yes, go out and check out JRuby or Groovy or Jython or any language that you're interested in, have a look at the implementation, play around with the language a little bit, maybe make a contribution back to the program, back to the implementation in the form of patches or bug reports. These are almost all truly community driven projects and the best way we can improve dynamic language support on the JVM is by working together as a community to help these projects out.
I think this is going to be the year of dynamic languages on the JVM, so it's a good time to start looking at them.
TSS - Charles, thank you for your time.
