Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

Ruby is for Java

If your architecture involves both Java and Rails on the server-side, there's a good chance you've had to do some creative engineering over the past few years to deploy your application.

In the associated audio interview Bob McWhirter, JBoss Fellow, Codehaus Despot, and creator of TorqueBox, discusses the boundary between Java and Ruby and his efforts to make Torquebox "a real first-class Ruby platform that works the way Rubyists expect".

McWhirter will expand on many of these ideas during his session at next week's OSCON Java conference in Portland, Ore.

An Interview with Bob McWhirter on Torquebox, Java, and Ruby

(For the textually inclined, a full transcript from the McWhirter interview is posted below).

Bob McWhirter: I am Bob, Bob McWhirter. I have a couple of titles, I guess, but currently I am the JBoss Fellow with Red Hat, which means I get to go do research and development and figure out what the next cool things we're going do are.

Previous to that, of course, I was the founder of The Codehaus, and I've been involved in open source for probably 10 years now, if not longer.

Tim O'Brien: What is your session going to be on?

BM: The session that I'm giving these days is typically talking about the power of Java, but with the beauty of Ruby, that you don't have to start over from scratch just because you change languages. You can take all the great stuff you know, whether it's third-party libraries you're using or if it's your own legacy components and be able to use them and take baby steps into the world of Ruby and to taking advantage of the beautiful expressiveness of Ruby.

TO: Java programmers learning Ruby. Is that a wave that's already passed or do you think that's a wave that's just starting to crest?

BM: I think we kind of go in a couple of cycles here, honestly. There was a big surge in Ruby a couple years ago where a lot of Java people just got pissed off and annoyed with Java enough to jump over to the world of Ruby. That was kind of a rebellion, if you will, kind of a heartbreak where they gave up on Java and moving over to Ruby.

I think now, though, we're seeing a more rational kind of move of people who want to just add Ruby to their toolbox. Not necessarily trying to rebel against Java and get away from Java, but just trying to get away from quite so much Java.

One of the things I'm seeing more of is where people are taking their legacy components, but let's say, rewriting a front end in Ruby. Their view layer or whatnot, or maybe building small little departmental type of applications with Ruby just to get their toes wet. And really evaluating it in earnest, as opposed to as a rebellion or as a fed-up-ness with Java or whatnot.

We support CDI in TorqueBox, so you can inject your Java bit over into your Rails application and use them. You can get started really quickly and really easily with your existing stuff and just "let's throw up a new web page that's written in a Rails app or a Sinatra app".

I think we're just at the beginning. I think as JRuby gets better and as things like TorqueBox continue to improve - and particularly if we ever get, let's say, a supported offering behind it where you can go choke Red Hat's neck if something breaks - then I think that will give more enterprises the comfort level they need to move over to Ruby or to start experimenting more with Ruby.

I don't think it's passed us by. I don't think we've missed this boat and we're going to lose it to Scala, however it's pronounced, or anything. I think the market will continue to grow for Java people who are moving over to Ruby.

OSCON Java 2011, being held July 25-27 in Portland, Ore., is focused on open source technologies that make up the Java ecosystem. (This event is co-located with OSCON.)

Save 20% on registration with the code OS11RAD

Torquebox: What problem does it solve?

TO: You were working on Ruby and Java stuff for a while, a couple years now, three or four years?

BM: Yeah, a little over two now, about two and a half.

TO: Why did you start paying attention to this?

BM: It's a little on the winding road. I joined JBoss four years ago, I guess, and I joined as a manager and I learned pretty quickly that I'm not a very good manager. So I took a sabbatical from the job for about three months. With a friend of mine, who I now work with, we started trying to do a startup and we, like any other startup, we did it with Ruby on Rails.

I really liked that environment and I had used Ruby on Rails before, of course, building the Codehaus. I really liked it, but my sabbatical was up, the startup failed, and I had to go back to this Java Corporation. I'm thinking, "Well, what can I do to take my love of Ruby on Rails and still get a paycheck from the Java Corporation?"

Thankfully, JRuby exists, and start gluing it onto JBoss AS. Being a fellow thankfully meant that I didn't have to produce revenue pretty quickly or anything. So I could take the time to look at how do we take JBoss AS5, at that point in time, and glue JRuby to it and make a good experience for Rubyists. And also give Java people an alternative, if you will, a way to start playing with Ruby without having to change their entire platform.

My first goal was really just to get Rails running on top of JBoss using JRuby. Then from there it's like, "Well, we got that done. Let's add to it. Let's do more. Let's make it enterprise-y."

TO: Coincidentally, JRuby was a product of Codehaus. It still is.

BM: Yeah, it's had a weird history. Charlie Nutter kind of drives it now with Thomas Enebo. But they weren't the founders. I'm not sure who actually started the project. At some point it was over at Kenai for a while, Sun community. Then part of it was at Codehaus. Then I don't know what Kenai is up to or

It's unfortunately one of those projects that's scattered around. But the fact that it's having some touches with Codehaus, I think, does make it easier for me to work with those guys and get to know them and have a little mutual respect because TorqueBox ultimately benefits them and JRuby certainly benefits TorqueBox. So it's a very symbiotic relationship I have with those guys.

TO: What was the main technical problem that you were trying to solve?

BM: It's really kind of two-fold. The first problem doesn't involve JRuby Rack. It actually involves Warbler, or previous to that it was GoldSpike, I believe it was called. Which is where you can take your Rack application or your Rails application, bundle the JRuby Rack and stuff it inside a WAR file. Then you go deploy this WAR like you would any other WAR file. Your app server doesn't know anything other than WAR file.

The problem I have with that is that I'm having to stuff everything inside a WAR file, basically a packaging step. One of the beauties about Rails work is that you can edit your files there, live, on disk. You have your whole source tree laid out and your app is running from that source tree on disk. There is no compilation. There is no packaging. I edit a model. I edit a view. I edit a controller. Those changes are picked up live. If I have to stuff everything inside a WAR file I've broken that quick development cycle. I now have to edit code, package, deploy, and then test.

With regular Rails development I just edit and I go to my browser and hit refresh and I see my changes immediately. That was what I didn't like about Warbler as far as a way to deploy Rails applications on Java app servers. Certainly made it possible, but it didn't make it fun and easy and it lost a lot of the cool stuff you get from developing in Rails in the first place.

Now, that's not such a big deal if you're developing just vanilla Rails apps that run the same way under MRI, traditional Dbase Ruby or run under JRuby inside a WAR. You can develop under one platform, package it and deploy under another. But there you're only dealing with the web part of the problem.

That's the second half of what I was trying to attack, was that our apps are so much more than web and Rails is only just web, Rack is only just web. But what we do for daemons, what do we do for handling message queues, that kind of stuff.

That's where I find a lot of the fun development going on in TorqueBox. We get to take these functional solutions that the Java world has and map them down to the Ruby APIs or create Ruby APIs for them and make it a joy to work with like message driven Beans, if you will, from Ruby where you never have to think about message driven.

Once you do that then you can't do this kind of stuff under MRI, traditional Ruby, so you can't just develop an app under MRI and bundle up in a WAR and send it over to your app server. So that's where we decided to try to make TorqueBox a real first-class Ruby platform that works the way Rubyists expect. No more packaging in to WAR files or anything with Warbler.

Then also give them more than just the web components. That's where we start bringing the message listeners, start bringing scheduled jobs and daemons and things to the app server.

Get rid of the ads (sfw)

Don't be the product, buy the product!