W-JAX 2009: JRuby on Rails – Grundlagen für Umsteiger

Disclaimer: This entry has been written while listening to the talk. Please forgive me any typographical or grammatical errors resulting from this approach.

Michael Johann is gowing to present JRuby on Rails and its strengths, in particular when trying to use the available Java libraries. Since I am very interested in “better web development” I finally want to take a shot at what JRuby and Rails have to offer. Here were go…

The attendance level for the talk does not qite seem to match the enthusiasm constantly implied by the (J)Ruby community for its offerings – but maybe the talk is too basic or most people are already using JRuby and thus need no “conversion talk” or I am just feeling too tired or cynical this morning for a decent blog entry introduction 😉 . Back to the actual content…

While shortly explaining his bio (founder JavaSpektrum, founder RailsWay magazine among others) he quipped that most money still is made with Java EE and not with (J)Ruby – although it has a lot of potential. A short survey with the audience showed that few people have actual Ruby experience, Rails knowledge is even more rare and a side remark of Michael implied that there might be good reasons for not using Rails… although he didn’t elaborate.

Next he introduced Ruby and JRuby as a strongly typed language with JRuby being JVM based. Ruby is partially implemented in C, partially in Ruby. JRuby replaces the C parts with Java code. JRuby by now is the fastest Ruby implementation being available. A major selling point of Ruby seems to be Rails… without Rails most people seem to find nothing useful in Ruby – so I probably misunderstood Michaels initial Rails remark.

Michael has provided an entry for the W-JAX code challenge based on JRuby on Rails.

JRuby is made up of

• the interactive ruby shell (JIRB, JIRB_SWING),
• Gems (system wide library, comparable to JAR files),
• Rake (like Ant oder Make).

Ruby on Rails is an MVC based web framework. It’s free, test-enabled and has a lot of plugins. It focusses on form based web applications of limited size. It is definitely not suited for large banking applications with thousands of tables, etc. But you can build the web interface for such applications with JRuby on Rails at extreme speed and then integrate with classical Java libraries – taking the best of both worlds.

Next Michael introduced JIRB and shows some quick code examples in the interactive shell. He showed basic concepts like “everything is an object” and reflection. jirb_swing is the interactive JRuby shell based on Swing with one important extra feature: tab completion. Michael noted that JRuby converts camel case Java method names to the JRuby naming convention (all lowercase and using underscores, e.g. using set_color instead of setColor). Nice, but do we really need that? But okay… I wonder what happens when a Java class implements both “setColor” and “set_color” – for whatever reasons.

Then Michael demoed a small Swing application and illustrated how to compose a few Swing elements in JIRB. The important point of the demo was that developing an application does not necessarily involve code compilation but rather only scripted development. Nothing truly new – I have been doing that with Tcl/Tk in 1995 but it’s nice to have it in Java…err…JRuby nonetheless.

For programming Michael used TextMate on his Mac… I immediately got concerned about real IDE support… but maybe that’s not necessary for typical (J)Ruby applications. Michael advised that programming in (J)Ruby is so easy that you won’t need a complicated IDE but a simple text editor is sufficient. Your mileage may vary.

Michael explained his Swing TODO application line by line showing the major differences between Java and Ruby… for me Ruby appeared like a little Java, a little Perl and a little from everything else… which is not necessarily a bad thing. To integrate C libraries (J)Ruby offers FFI (foreign function interface) which allows direct access to C libraries. That actually is very nice compared to JNI.

As far as learning (J)Ruby is concerned, Michael proposed “about three days to fully grok the syntax” and “another half year for the huge libraries”.

The next demo involved a small Rails application. Michael explained the simple folder infrastructure used a standard for each Rails application, the staging concept and the hotswap feature for controllers and view (but not for models – he was very careful about that issue). He illustrated using the Rails generator (command line based) in order to scaffold a small blog application. A couple of dozen of source artifacts got generated. The he demoed the generated CRUD web interface. Side remark: I learned about LoremIpsum.de – what a neat website. I learned that JRuby on Rails allows for decent CRUD prototyping. I recommend to everyone to have a look at Intrexx – it allows that, too… but at a much more advanced level. And it is Java-based and even will have Spring support in the upcoming version 5. Michael next explained partials as a component concept to compose web pages from individual parts. His demo application for the W-JAX code challenge wasa written in about 5-6 days, Michael guesses that one needs a couple of weeks of training and experience to get to that level of coding skill. The application (including Twitter integration, stats, login, etc.) has about 828 lines of hand-written code and includes (auto-generated) default tests covering about 90% of the code (Michael admitted that the true value of these tests is debatable – they test that the application runs when it is started).

Michael recommends to at least take a look at (J)Ruby in order to get inspiration for daily Java work, even if one does not use (J)Ruby itself.

As for performance he mentioned that Ruby in itself is a performance problem – but that this situation is similar to Java in 1994. Performance quickly was relegated to a hosting topic. On the other hand JRuby is the fastest Ruby interpreter available… but still much slower than Java. Xing seems to run on Ruby in large parts which I find very interesting… Twitter still has large parts on Rails. Michael again stressed the (IMHO correct) point that the performance problems mostly arise due to wrong use of Rails… Rails is only meant for the web interfaces. He remarked that he wouldn’t use Scala neither for Twitter… maybe Erlang due to the high messaging requirements.

Michael sports a very casual and funny style of presentation – I loved listening to him. His content was to the point and very interesting. I found his opionions to be devoid of hype and very honest… quite refreshing to other statements I have seen from other parts of the (J)Ruby community. Thanks for a great introduction to JRuby on Rails.