Not much was expected from this year’s Java love fest, the JavaOne tradeshow. At last year’s event, many attendees and vendors predicted that 2009 was the last instance of JavaOne. The acquisition of Sun by Oracle furthered this view, as Oracle already had no strong tradition of for underwriting developer tradeshows.

So when the company announced that it would indeed host JavaOne in 2010, I was delighted. This show has consistently been one of the better developer confabs on the calendar. However, Oracle scheduled it to run contemporaneously with Oracle Open World, which by itself is one of the biggest technical tradeshows held in North America. As such, JavaOne was sequestered in a hotel blocks from its usual home along with Oracle’s non-Java classes.

In the time leading up to the show, events were promising to make it more and more interesting. First, Oracle sued Google. Then, James Gosling, the putative father of Java, promised to launch a campaign to “free Java” that would culminate at JavaOne. Ultimately, though, both drivers provided far fewer fireworks than expected. Google pulled out of the show, and Gosling’s protest appeared to garner no support. I believe I saw two shirts supporting Java freedom during my time on site.

More importantly, there was no Java news of consequence announced during the show. So, rather than an event, it was more a series of training sessions with an exhibit hall thrown in. One has to hope Oracle will not run it in parallel with OpenWorld next year, as that schedule will relegate JavaOne to a footnote.

The sparse news was in contrast to what was happening in Ruby land. Rubinius, one of three Ruby implementations to run Ruby on Rails (the other two being the mainline Ruby MRI and JRuby), saw its first major post-1.0 release, with greater stability for running Rails and various performance improvements. This followed the release of Rails 3.0 from just a few weeks earlier, which cleaned up Rails internals and added numerous features that have already been covered in this publication. These two releases were already far more action than what I was seeing at JavaOne.

While new releases of marquee products are important for any language, it isn’t this activity that is making me excited about the future of Ruby as much as it is the progress of a single project: JRuby.

JRuby is a version of Ruby that runs on the JVM. It’s been under fairly constant development by a trio of programmers from the Midwest, who initially worked at Sun and are now sponsored by Engine Yard. It is written entirely in Java, so it runs without difficulty on the JVM and can integrate seamlessly with Java’s vast libraries and the large ecosystem of third-party products (an ecosystem whose scale dwarfs that of Ruby’s).

The language implementation is compatible with Ruby MRI, and is thereby sufficient to run Rails and all major applications. Moreover, it runs them faster than Ruby MRI (when you remove the startup penalty for Java). This is an important dimension, as performance is a constantly mentioned defect in Ruby. For example, in the recent Alioth benchmarks, Ruby MRI comes in dead last among all languages tested on single-core 32-bit and 64-bit platforms. (It was not run on the multicore benchmarks.) JRuby significantly improves on these results, although it remains in the lower half of language performance results, on par with Python 3.

If performance is the biggest barrier to user adoption of Ruby, the generally unknown VM of Ruby MRI is the gating factor for its acceptance in IT. Managers and administrators are not keen to add a new platform to the list they already support. With JRuby, this problem vanishes, as most IT departments are entirely comfortable running Java on their systems.

Java developers could find JRuby to be an attractive tool as well. The JSR-223 mechanism in Java 6 enables Java programs to invoke a script engine from inside an application. This means that if a Java app needs a scripting interface, it can add the JRuby engine to interpret and run the scripts. (Java defaults to calling Rhino, a JavaScript engine, but changing scripting engines is trivial.)

Beyond these points, there’s another dimension that’s convincing me: JRuby looks like the central hub of activity in Ruby these days. It would not surprise me if it becomes the gateway to much wider adoption of Ruby and ultimately emerges as the reference implementation by sheer force of numbers. Such a scenario is at least several years off, but it’s clear that for developers who write to the JVM, JRuby is an excellent solution when choosing a scripting or development language.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.