This post originated from an RSS feed registered with Ruby Buzz by Obie Fernandez. Original Post: JRuby Progress Feed Title: Obie On Rails (Has It Been 9 Years Already?) Feed URL: http://jroller.com/obie/feed/entries/rss Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Obie Fernandez Latest Posts From Obie On Rails (Has It Been 9 Years Already?)

[I'm reporting from the RubyConf 2005 convention in San Diego for the next few days.]

After lunch today, Charles Nutter presented a enthusiastically-received report on the progress of the JRuby project, which is an implementation of a Ruby interpreter that runs on a 1.4+ JVM and allows access to Java libraries from Ruby code. It's been four years since the project started and gone through 15 developers. There are currently 3-5 active developers and the codebase is under heavy development (actually, it's a re-write because the earlier version was bad).

require 'java'

The first code demo shows how easy it is to access Java apis (see above) and demonstrated adding functionality to the auto-generated proxies that wrap java.sql.ResultSet when those are accessed from Ruby code.

These kind of projects (JRuby, Jython) go a long way in helping to distinguish the languages from their C-based interpreter executables.

JRuby will have permanent incompatibilities (from a Ruby perspective) around system calls, C-language Ruby extensions, anything to do with C, or platform-specific operations that aren't supported in the JVM.

The second demo showed stark contrasts between the recursion performance of normal ruby (shallow stack because the interpreter is extremely recursive), jruby (somewhat better) and the new "stackless" implementation of jruby. With the stackless interpreter, stack-depth was limited only by available memory. He showed a fibonacci calculation of 3000 (64MB), then 150000 (1G) with amazingly good performance.

The team is following the direction of maintaining behavior of Ruby as it exists now rather than trying to "correct" any inconsistencies of the language as they go along. This will maximize compatibility in the short term, but with a view to pushing the specification of the language forward in the future by merit of larger numbers of users.

On another note, my colleague Nat Pryce is blogging about some really great work with "Higher Order Messaging" in Ruby (and part 2). It allows you to write much more readable Ruby code (yes, you read that correctly so go check it out now!)