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

July 19 2011

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 Java.net.

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.

July 07 2011

A rough guide to JVM languages

O'Reilly is celebrating the release of Java 7, and our inaugural OSCON Java conference: July 25-27 in Portland, Ore.

The possibility of using alternative languages on the JVM has always been an appealing side story to Java. Jython and JRuby were early pioneers in implementing a dynamic language on top of a statically typed VM. Now that Java 7 directly includes support in the JVM for dynamic languages, the coexistence is official.

Pick any of the languages here and you can expect the support of the robust JVM threading and garbage collection, plus access to a broad array of application libraries.

Up and coming

Scala

The pragmatist among JVM languages, Scala is a general-purpose programming language. It was conceived and is generally viewed as a "better Java," and of all alternative JVM languages has the best acceptance in an enterprise setting.

Scala combines the familiar feel of object-oriented Java with strong language support for concurrency, XML and functional programming features: many of the tools that contemporary complex and scalable systems require. Scala also takes a lot of the awkwardness out of Java code, through features such as type inference and traits.

object HelloWorld {
    def main(args: Array[String]) {
      println("Hello, World!")
    }
  }

Scala-related content at OSCON Java:

OSCON Java 2011
To celebrate the release of Java 7, the first 77 people registering today for OSCON Java with code JAVA7 will get the pass at a discounted price of $700 (applicable to OSCON Java package only).

Register now with code JAVA7

Clojure

Clojure is a functional programming language based on Lisp. Through careful design, Clojure is simpler to read and use than Lisp, and it interacts cleanly with the Java world. Its functional nature makes programs very concise and composable.

In common with Scala, Clojure is designed with concurrency in mind. Its variables are immutable, and the use of software transactional memory and agents help manage shared mutable state in a more sustainable way than locking.

The experience of Clojure's inventor Rich Hickey is reason enough alone to give it a whirl. I once happily spent an hour listening to him describe the design and implementation of sequences in the language.

A "Lisp that could," Clojure is finding increasing (and surprising, to most observers) traction and acceptance. One contributing factor to this is an advanced build and package management infrastructure in leiningen and Clojars. Salesforce-owned hosted platform provider Heroku recently added Clojure as its third supported environment, following Ruby and Node/JavaScript.

A small but important omission from the Clojure ecosystem is a port of the book The Little Schemer.

(println "Hello, World!")

Clojure-related content at OSCON Java:



Tried and tested


Groovy

A mashup of ideas from Python, Ruby and Smalltalk, Groovy gained early traction in the world of JVM languages, reaching its stable release in December 2007. Having been around a while, Groovy strongly acknowledges the Java world into which it was born, and is a good choice for Java developers wishing to use a more agile and dynamic language.

One of Groovy's jewels is Grails, a high-productivity web development environment inspired by Ruby on Rails. The Groovy world has also spawned Gradle, a modern project automation system for Java and JVM languages, providing an alternative to the established Ant and Maven projects.

println "Hello, World!"

Groovy-related content at OSCON Java:

Rhino

Another veteran of the JVM language scene, Rhino is an implementation of the JavaScript programming language in Java. Part of the Mozilla project, it is typically used by developers to add user scriptability to their applications using JavaScript, though it is also used in situations where a system is predominantly implemented in JavaScript.

First released in 1999, Rhino has been around the block a few times. As a JavaScript engine, it is facing increasing competition from the C++-based V8, but retains the immense advantage of Java interoperability.

print('Hello, World!');

Remastered classics

Jython

A port of the Python language to the JVM, Jython offers some advantages over and above using Python, including Java's multi-threading and the ability to statically compile into Java classes. As a Python terse object-oriented language, programmers can quickly prototype in Jython, creating hybrid Java-Jython systems. Jython also offers developers an alternative to Rhino's JavaScript for embedding scriptability in their applications.

Jython also lets web developers bring popular Django web application framework into a Java setting.

print "Hello, World!"

JRuby

The Java implementation of Ruby is no second-class citizen. JRuby has been recorded as better performing than Ruby 1.8, and strives for C-Ruby compatibility. Users of JRuby can benefit from using the Ruby on Rails web framework, or add Ruby scriptability to their applications.

One appealing aspect of building a system in JRuby or Jython is that it gives developers the option of reimplementing performance-critical code in Java without having to switch platforms as a project matures. Twitter's migration from Ruby to the JVM is a case in point.

puts "Hello, World!"

JRuby-related content at OSCON Java:

The Wild West

The JVM remains a fertile ground for language experimentation, as several of the languages featured in OSCON's Emerging Languages track demonstrate, including Seph and Gosu. As a platform, the JVM bootstraps language inventors and experimenters today much as lex and yacc did two decades ago. At OSCON Java, aspiring language creators should pop along to Charles Nutter's JVM Bytecode for Dummies.


There's still time left to register for OSCON Java. See you in Portland, 25-27 July!



Related:


Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
Get rid of the ads (sfw)

Don't be the product, buy the product!

Schweinderl