You may also download this file. Running time: 00:26:32
Henry Liu and Justin Edelson wrote the just released JRuby Cookbook which is available from O'Reilly in both Print and Electronic formats. I spoke with both Henry and Justin about the book, JRuby, and the current state of the Java platform. Here's the transcript of our interview.
Tim O'Brien: Let's just dive in. You wrote the JRuby Cookbook - the two of you wrote this book. Could you talk to me a little bit about what's in the book and who you think should buy it?
Justin Edelson: So I'll start. The book really covers a variety of facets of using JRuby. I think it was important to us that this not just be a "JRuby on Rails" book. Ola's book is really good and covers that subject in a fair bit of depth, so we wanted to cover - we certainly talk about rails, but we wanted to look at the whole JRuby ecosystem and the various things that you can do with it. So those range from just using JRuby as a scripting language inside a Java application - there's a whole chapter about GUI applications.
We talk about build/deployment/testing, that sort of stuff, as well as obviously covering Rails, which you couldn't write a Ruby book and not touch on Rails. So we really try to cover a wide gamut of different application types.
Henry Liu: Yeah, and just to add something, I think that the general philosophy or the idea behind the book is sort of taking the practices that happen in the Ruby community, like continuous integration and sort of exploring that intersection with a lot of the common Java practices and a lot of the common Java software. I think that's where you're trying - I think that was the sort of voice they we trying to project out of the book. At least that was what I was trying to project.
Tim O'Brien: So it's more than just JRuby on Rails book. It talks about how to use JRuby inside of a Java application that already exists?
Justin Edelson: Yeah. I think we touch on a few different ways of doing that from using just the JRuby interpreter directly. We talk a little bit about the enscripting framework as well as the newer Javax scripting package to really do language-level integration. And then we have a number of recipes that are focused around using JRuby to define beans in a Spring container, which is a really nice way of making other parts of your application use JRuby, but they don't necessarily need to know they're interacting with JRuby. So using Spring is sort of a mediator there.
Tim O'Brien: I was talking to the Spring Source CEO, Rod Johnson, although I'm not sure if it was the CEO or not. He's definitely one of the primary forces behind the company, and we were talking about Groovy and Gr ails and Spring, and he said that there was less of an impedance mismatch between Groovy and Java, and that there was something of an impedance mismatch between JRuby and Java. Could you talk about that?
Justin Edelson: Well, I'm not sure exactly what he means. I'll say that I think Henry and I both found that the lack of annotation support in JRuby led to a few problems, and so I could definitely see that if - because so much of what Spring has been doing in the 2.0, especially in the 2.5 release, has been annotation-driven, I could see that being an area of mismatch, whereas Groovy as of 1.5 has support for annotations. But on the whole I'm not quite sure what he's referring to.
Justin Edelson: So there's nothing preventing you - from JRuby you have access to the whole of any API in Java, and so there's no real conceptual reason why you can't just "new" up a Spring application context that actually you could have it be a JRuby initializing a Spring application context in which all of the beans are defined in Groovy. That's certainly possible, although we don't go into detail on that in the book.
Henry Liu: I think it actually gets more interesting though when you look at some of the sort of flip side is when you have a Spring container, you're in Spring, and then you can use Ruby to define your controllers. I think that's sort of the angle that we really explore in the book, and that's really where we see the benefit because you get that benefit of not having the benefit of descriptive language, where you don't have to compile things. You can just deploy the scripts up into your production environment and it'll just pick them up right on the fly.
So that's sort of - we sort of look at that aspect of the problem more and not really the given a Ruby application using like an inversion of control container like Spring in your applications.
Tim O'Brien:So if I were working on a Spring-MVC front end for a (Audio Glitch) application I could write one of my controllers in Ruby, and I could (Audio Glitch) right. What is involved there? One of the things that I have always thought is the reason why people don't get into JRuby is what has to be on a class path? Is it just a Jar file for JRuby? Okay, how do I gain access to say something like a gem? Could you talk about that, just the basic process of integrating JRuby and all of the things that come with Ruby into a JVM.
Justin Edelson: Yeah, so from a base standpoint you really just need the JRuby JAR, and this is an area where I think Maven becomes very helpful as a build tool in that you can just add a dependency to JRuby and it's on your class path bundled in your WAR or whatever the deployable unit is. From a gem perspective the primary way of integrating that is you basically set some system properties that let the JRuby runtime know where the gem path is, and we talk a lot in the book about different gem manipulation or management techniques, I should say. There's one use case where if you're using both CRuby and JRuby you might wanna point them to the same gem path.
In another context maybe you want those to be totally separate, and through just manipulation of the command line you can say install these gems to a shared location or to a sort of private location. And then when you run your Spring application in this case you would just make sure that you're setting the JRuby home environment variable correctly to point to your gem install location. And for pure Ruby gems that don't have any need of code, the same gem works in either environment. Obviously native code is a different story.
Tim O'Brien: What is the general sense in terms of gems? So if you look at something like Ferret - is Ferret all Ruby or does Ferret have some C components to it?
Henry Liu: Ferret? That's the search engine, the Ruby search engine.
Tim O'Brien: Yeah.
Henry Liu: I think it actually does have C bindings to it, last time I - at least when you - yes, go ahead.
Tim O'Brien: So how do you find a way around that? I mean, is it just the case that there are certain gems that you just aren't gonna be using from JRuby, and if so, what's the percentage?
Henry Liu: So basically, yeah. If you have gems that have native parts to it that'll compile in C then you have a couple options. The most common gems, like for example RMagick or Hpricot or even Mongrel, they all have JRuby implementations of it, so the parts that are done in native code have been implemented in Java. So you can install this alternative version of the gem when you're in a JRuby environment. The other option obviously is to just do your own porting. You can dig down in and sort of go through the same task. But yeah, those are probably the few main approaches that you'd take if you had a gem that - and in terms of percentage, I can't quantify that.
I have no idea. But the most popular gems at least have been moved across and/or are in the process of being moved across.
Justin Edelson: And there are also a couple of examples where - you know, Henry mentioned some of the image manipulation stuff where I think it's primarily the JRuby team or other volunteers have created API-compatible versions of those gems that instead of using a native layer use a Java layer. And especially I think we found that to be the case around image manipulation, but there's a lot of stuff now in the JRE to handle image manipulation. So all the team has done is really write a wrapper around that that emulates the image science Ruby gem API for example.
Tim O'Brien: For the record, I'd just like to say that installing RMagick in CRuby is something of a pain in the neck, so would you say that it's more or less easy to use the JRuby version?
Justin Edelson: I think there are some font issues that sort of get in the way of doing a -
Henry Liu: Yeah, I think in general it's easier because obviously you don't have to install the RMagick, which depending on your platform can be difficult. But I think the one problem right now is that they have a lot of the library, and every time they release it they have more compatibility with the C version of RMagick, but it's still lacking a little bit in terms of complete compatibility. So I'm sure that there are a lot of fringe cases out there where there may not be 100 percent compatibility. But it's definitely improving, and with every version it gets closer and closer. And it's something I think they're obviously working on.
Tim O'Brien: One of the old JRuby blog posts I think was by Ola Bini, and he talked about how you could use JRuby to sort of launch up the JConsole, and you had more transparency as to what was going on in your application. Could you talk to me about some of the things that are possible in a JRuby app that are not possible in a plain old Ruby app?
Justin Edelson: I think the stuff that Ola's talking about there in monitoring and manageability is really key. JMX in the Java space is pretty well established and there's a solid maturity of the ecosystem; things like Hyperic or even just JConsole and Visual VM, which are now included in the JRE, and the ability to expose arbitrary parts of your application for management is a really nice thing that the Java platform just provides now. I know in the work that Henry and I do there's historically we've done a lot of monitoring at the system level - free memory, thread use, things like that. And being able to bring monitoring up the application stack and say how's this cache doing, how many times are people ordering something?
And then using off-the-shelf tools that know how to speak JMX to graph that is a big win, and something that I think the CRuby community is a little lagging behind the Java community, just because Java has been sort of enterprise focused.
Henry Liu: I just wanted to add one more point about the differences. I'm not an expert in this field, and I haven't really tracked the newest developments, but a lot of people sort of look to the threading support, and that's one main difference. Right now with Java you have the VM has evolved so far in ten plus years or even more in its life, and you have support for running on multiple cores, and you have the threading model is just a little bit better implemented and a little bit more robust. You have real preemptive multithreading as opposed to a lot of the earlier Ruby implementations. I think, I'm not sure, with 1.9 there may be better support, but I don't know for sure.
Tim O'Brien: Question about the Ruby community - the Ruby community - oh, I should be more specific. The Rails community was sort of founded with this ethos of anti-Java bigotry. Now, that might be an unfair word to use. Let's just say they had strong feelings against the Java language specifically. How has that changed? Has it changed? Can you talk about some of the places where the communities don't see eye-to-eye and some of the places where they do?
Henry Liu: I guess when I used to go to the early NYC Ruby meetings, yeah, it was definitely a really interesting crowd, because you had this one side of people in the room who were hard-core Ruby people and never wanted to know Java or learn it ever. And then you had people like myself who had years and years of Java experience, dying to learn some new technology. And I think it's always been kind of an awkward match to not necessarily a perfect kind of marriage in any way, but I don't know. I think JRuby is sort of that attempt to bridge that gap a little bit and try to have these kind of groups see eye-to-eye a little bit, but I can't honestly say that I see that much.
There isn't like this Kum Ba Yah moment where people are just holding hands and coming together. I think that the Ruby people still tend to look for their solutions using the Ruby technology and writing their technologies in the Ruby code; using Java when absolutely necessary, but generally still looking toward Ruby-oriented solutions. I don't know exactly how many Java developers are crossing over to Ruby, but probably more and more hopefully with the book.
Tim O'Brien: Do you want to comment on this, Justin?
Justin Edelson: I think what JRuby does is it actually broadens the playing field a little bit for Ruby in that as Henry said, especially around Rails. The audience for that has been people who frankly in a lot of cases were just burnt out on Java, and what JRuby has allowed is to bring more Java people into Ruby and create more deployment opportunities. To me that's really the biggest area which JRuby brings to the Ruby language is more deployment opportunities, especially within the enterprise where things like JBoss or BA are well-established technologies.
And we really aren't - systems people aren't particularly interested in running Mongrel or other Rails-oriented containers - or Ruby-oriented containers, I should say. And JRuby really allows the broadening of that playing field for them.
Tim O'Brien: So one thing I just have to ask you is both of you are Java programmers. You would call yourselves Java programmers, I guess, if I forced you to choose a language?
Henry Liu: Yeah, I would have to say that. I mean, I do a lot of Ruby development but I think in terms of the mindset, yeah, I'm definitely more of a Java developer.
Tim O'Brien: And Justin?
Justin Edelson: I disagree with the question a little bit. I think we're not - well, in all seriousness, I don't think that we're language - I don't think of myself and I frankly don't think of Henry as a particularly language-oriented developer. I think we're software developers, systems architects, at the core, and we're really interested in finding the right tools for the job. There are certainly people who are Java developers, and when all you have is a hammer everything looks like a nail. But I think especially in this environment you need to be really picky about which tools you use for which job, and find solutions to problems.
And I think that's what I've tried to do, and in working with Henry that's what I can see that he's tried to do. So I would disagree a little bit with the characterization that we have to be one or the other. I spend I feel most of my time in the build and deployment world now, but that's not how I would define myself.
Tim O'Brien: Well, if that were a trick question I think Justin just got an A+. But the reason I ask is because it seems like Java has been having an identity crisis for years and years and years, the platform. Some could argue that it's healthier than ever; some could argue that it's on its last legs. But it's clear that Sun has had a problem devoting resources to it, or at least if you look at something like JavaFX, there have been a series of failed efforts to sort of inject more energy into the platform. Could you talk to me a little bit about whether or not your interest in Ruby is something that is a reaction to that, or is it something that you think would've arose naturally despite what's happened to the platform?
Justin Edelson: It's a little hard to say. I think especially what's happened with Rails has been a recognition that the way that we have been doing development - divorce it from any particular language. But the way that we've been doing development needs to be shooken up a little bit, and that to me is what Rails ultimately did because at the core of Rails all of the MVC stuff is nothing particularly new. The big thing at least that I took away from working with Rails is the fast turnaround development, and that's what - looking at that you said, "Wow, I really understand how this changes the game." The controllers and all that sort of stuff, that's nothing new - it's the process changes. So I think Sun is in a position where they need to try to make the language and the platform more agile and more easily adaptable to change.
Tim O'Brien: Do you think that they're succeeding in doing that?
Justin Edelson: Well, they employ Nutter. I know Henry - and maybe Henry can speak more to this - was really impressed with NetBeans. Not a thing - I have not used NetBeans a lot; historically I'm an Eclipse person, and that I will characterize myself as an Eclipse person there. But I think they are making some strides in that direction. I don't really understand JavaFX - I'm not sure where it fits in. I understand the language; I'm not clear what the strategy is behind that, but they're trying.
Henry Liu: Yeah, and like Justin mentioned, I think that they're doing - I think it's sort of they got a couple hits, but they also have some misses or some half-assed work, I guess. The NetBeans I think is one of the definite better areas. The idea is really good. The feature set is comparable in a lot of ways to Eclipse and to the other popular IDEs. Actually in some things they do better in terms of completion of Ruby code, especially for JRuby developers. JavaFX - I don't know. I worked on a lot of the GUI chapter so I looked at JavaFX a lot and thought about it in comparison to a lot of the technologies that we talk about in the book.
My take-away was that what I thought was interesting was the scripting language itself, ultimately; the JavaFX language that you use to sort of create all the logic and define all the actual components. I just thought compared to Ruby or to JRuby at the end of the day it was just second-rate, and if that's really all that the technology is bringing to the table, this sort of scripting language, I think a lot of the ideal alternative techniques that we talk about in the book are much better. I mean, the only issue is a lot of it is tied into Swing, or a lot of the examples we talk about Swing, but there are also newer GUI technologies that are emerging that are using their own drawing toolkits.
And accessing them through JRuby can be as good as any JavaFX stack, in my opinion - not that I have done that much development, but just what I've looked at and a lot of the examples that I've looked at, it seemed to me that you could do as much or more over in the JRuby plus a toolkit world.
Justin Edelson: The other big win I should mention is GlassFish, which I think especially in the v3, Sun and the GlassFish team have really taken the bloated nature of the J2EE container, the Java EE container and taken that into account and tried to redefine it, which is why you see things like the GlassFish gem, which will allow you to run a Rails application in GlassFish using basically an identical mechanism to the way you would run it with WEBrick or Mongrel. And I know that the Grails team has actually done something similar recently where they're starting to use GlassFish in lieu of Jetty as a low-impact servlet container.
Tim O'Brien: I saw an exchange on Twitter between Tim Bray and someone who works for G21 yesterday. I think Tim Bray was asking, "Why did you switch to GlassFish from Jetty?" I didn't hear what the answer is. It seems to be bucking a trend, though. It seems like a lot of people have embraced Jetty over something like Tomcat. Is it just that they need more of the J2EE features?
Justin Edelson: I can't speak for everyone, but I can say that my perception is that Jetty is used much more in development than in production. And so that may be part of it is that you desire a development environment that's as close as possible to your production environment. So using something like JBoss or even Tomcat, which is obviously lower impact than say JBoss or BEA in development, if you're going for a rapid turnaround, quick reload of the container, doesn't quite work as well. Whereas I think the Maven Jetty plug-in has done a great job of really speeding up Java development.
So I would assume that that's part of it, is that more Grails applications or more JRuby applications are going to be deployed on GlassFish than they would on Jetty.
Tim O'Brien: How did the two of you meet - how did you start working on the book?
Justin Edelson: I've known Henry for I think five years now?
Henry Liu: Something like that, yeah; time goes by fast.
Justin Edelson: Exactly. We worked together at MTV Networks, where we both still work, and I'd come in as a software developer and met Henry pretty quickly, and we just worked on and off together over that span of time.
Henry Liu: Yeah, and I don't think that we've - sorry, go ahead.
Justin Edelson: Well, I was just gonna say that I was thinking about an anecdote, and I'll say that the first thing I can really remember talking to Henry about was telling him that the author of the Lemony Snicket books was a member of the Magnetic Fields, and Henry was unaware of that.
Tim O'Brien: I didn't know that either.
Justin Edelson: That's the first thing that I - I think he isn't actually a full member, but sort of a mostly member. I'm not -
Tim O'Brien: And that was sort of a key pivotal moment that was sort of like a -
Henry Liu: Eureka!
Henry Liu: No, I don't know. I think that we've just always worked closely, but not ever directly on the same project, I guess. But I don't know. Our technology department's pretty small and we work pretty closely together, so I've always been aware of Justin and I've always respected everything that he's ever - you know, if I've heard him speak about something he always sounded very intelligent, so I didn't think twice about working with him. And I did over the years I've kind of peeked through some of his code, and I saw that his philosophy of design and architecture was very consistent with things that I would work on.
I kind of knew based on what I'd seen in the past that we'd be a good fit for trying something like this.
Tim O'Brien: How did you write the book? Was it in DocBook? Was it in the Wiki?
Justin Edelson: We did it in Word, which I'm not sure I will do again.
Tim O'Brien: And who was the editor - was it Mike Loukides?
Justin Edelson: Yeah.
Tim O'Brien: And how is he to work with?
Justin Edelson: I like Mike a lot; it worked really well. Mike is a great guy to work with from my perspective on a technology book because he actually knows the technology. So he was always willing to push us to say what about this, what about that? I can see from a developer's perspective why this is important or why this isn't. So he had some really valuable feedback.
Tim O'Brien: Is this a Java book or is this a Ruby book?
Justin Edelson: That's the million-dollar question.
Henry Liu: I think it goes back to what I was saying - I think it's a little - I don't know. I think we're trying to be a little bit of both but trying to be its own thing. I think it's useful for both. It's the obvious answer, but I think that Ruby developers who want to learn how to leverage some Java technology to make their jobs easier, I think they can take a lot away from it. And I think that obviously Java developers who want to look at what's going on in the Ruby world and learn some of the agile practices that are happening there and learn some new ways of using their old technology, I think that they'll find that really valuable too.
Justin Edelson: Yeah, I think - and this may not be a popular statement - but I actually think at the end of the day the two languages as languages - they're not that different. And so my perspective is that somebody who's a Ruby developer is gonna get the Java parts. Somebody who's a Java developer is gonna get the Ruby parts pretty easily.