Thursday, December 07, 2006

Springy and JRuby, the Rest of the Story

While researching an article on Springy and JRuby, I spent some time with Jan Berkel of Trampoline Systems (Spring's developer). Since it didn't all fit in the article, here's 'the rest of our discussion'.

What made you decide to write springy in JRuby?

Jan: The goal for springy was to create a flexible and easy to use DSL to set up Spring contexts. Ruby just happens to be well suited for this task (Rails being the best example) and JRuby provides the necessary integration layer between the two languages.

What made JRuby a good fit fit for this?

Jan: JRuby makes it very easy to extend existing Java code: it is getting to a point now where the boundaries between languages almost completely disappear, at least from a Ruby perspective. You can use and extend Java classes in a very natural way whilst retaining Ruby's power and flexibility.

What problems did you have using JRuby?

Jan: The documentation is sometimes not very helpful or does not exist at all, so I often had to dig through the source code. However, there's a JRuby wiki now and as the community gets bigger things will certainly improve in this area. JRuby is moving very fast at the moment, so keeping up with recent developments (new features, bug fixes) takes up a lot of time.

Do you have any feel for how many people are using Springy outside of trampoline systems?

Jan: It has just been released, so I'd say there's little chance of someone else using it at the moment. I get the impression that a lot of Java developers still see Ruby more as a threat than as a chance to make their own development environment more productive. XML-based configuration will be around for a very long time as it is the established convention and supported by many tools. However, people already familiar with Ruby will find that writing their own 'mini-tools' can be a lot more powerful.

What other opportunities do you see for JRuby to impact Java development/developers?

Jan: In the short term I see interesting opportunities in areas like configuration management (as alternative to XML), build systems (as alternative to ant/maven) or testing (RSpec). In the long term JRuby on Rails will certainly play a big role, giving developers access to one of the most innovative web frameworks without having to sacrifice their previous investments in Java.

On a less technical note, I think that JRuby could also help to bridge the cultural differences between the two development communities. Java users will use more Ruby for various tasks, and Rubyists will (hopefully at some point) make full use of a JVM-based Ruby implementation, where C extensions can be replaced with Java.

How much is Trampoline systems using (J)Ruby?

Jan: We use a hybrid development strategy, using (C)Ruby on Rails for the frontend and Java for all backend related things (actually with bits of Lisp in it as well). It's really a "best-tool-for-the-job" approach, Ruby/Rails is agile and productive whereas Java is the big guy in the background who does the heavy lifting. They get along very well at the moment. We're looking forward to a production-ready JRuby on Rails, it will simplify a lot of things.

Our build system is based on Rake with some Java-related extensions (which we've opensourced recently — Jerbil). It reduced the complexity of our build system from ca. 1500 lines of XML to 180 lines of Ruby, largely thanks to Ruby's metaprogramming capabilities.

No comments: