Post-JRuby-1.0 Bits and Bobs

Posted by Nick Sieger Thu, 12 Jul 2007 08:27:00 GMT

Summer is settling in, and so is the JRuby 1.0 release. Most of the core team seemed to take some time off since the release, as the commits and lists have felt quiet compared to the frenetic lead-up to 1.0. I don’t know if that’s a good thing yet -- I’m not bold enough to suggest that it means that JRuby’s just working for everyone, and that the software is bug-free. There have been calls for a point release (probably 1.0.1) and a better roadmap -- we’re working on those and should have something in the next couple of weeks.

On the other hand, the number and quality of blog posts about JRuby seem to be steadily increasing. The number of compelling applications of JRuby, both in the Ruby/Rails and the Java worlds, are being demonstrated more and more. Here are a few examples.

JMS is turning out to be a great place to sprinkle some JRuby magic. Ola started by implementing direct JMS support for ActiveMessaging, eliminating the need for the separate poller process. Nutrun goes the other way and demonstrates how simple it is to run a broker, publisher and subscriber using ActiveMQ and a short JRuby script.

Jeff Mesnil has started jmx4r, a simple DSL leveraging JRuby to write monitoring scripts for your JMX-enabled applications.

Kyle Maxwell whipped up a compelling plugin for Rails in time for RejectConf using Lucene. Why imitate when you can use the real thing?

Zed Shaw has caught the JRuby bug, and decided to do his own take on scripted Swing applications with Profligacy. Check out the progression of examples as Zed hones in on his final product. As nap points out, Zed’s Layout Expression Language (LEL) is a refreshingly concise take on specifying UI layouts. Cleaner separation of component layout and event handling logic is also a big win. Move over Groovy SwingBuilder and JavaFX!

Last but not least, my own earlier proposal on Java interface integration has been implemented in current JRuby trunk. Along the way I found the opportunity to toss in some extra sugar and implement proc and block coercion to interfaces as well. This means you can pass a proc or block to a Java method and it will be converted to the appropriate Java interface type (e.g., Runnable and Swing/AWT listeners):

button =
button.add_action_listener do |event|
  event.source.text = "You pressed me"

If closures for Java can’t do this, they will have gotten it wrong. Note that blocks will be converted and used in place of the last argument to the Java method only; if you need to pass behavior to any argument preceding the last, use a proc. Here’s one example that gets progressively better as we switch over to blocks.

Two parting thoughts -- a couple of things that aren’t quite ready, but you should keep your eye on.

Glassfish dev Jean-François Arcand demonstrates parked Rails requests with Grizzly. And you thought you had to do comet-style request handling outside of Rails? The future of scalable Rails servers looks pretty good to me.

Finally, respected object technologist Alan McKean has started looking at object serialization and persistence for JRuby. You thought you had to wait for that Gemstone-thing that Avi Bryant mentioned at RailsConf? Maybe the wait won’t be too long after all...



  1. Avatar Dr Nic said 1 day later:

    JRuby and its community deserves a big hug.

    We have a billing system that has a limited set of ways you can communicate with it. One is a Java API.

    So, now we can communicate with the billing system via Ruby/jRuby. Now we can script it and web-app-icize it.