Thursday, April 24, 2008

JRuby at JavaOne "Script Bowl" Session

At JavaOne this year, there will be a session entitled "The Script Bowl", in which JRuby, Groovy, and Scala will face off on a series of challenges. I suggested that the list of challenges include a range of things each of our language communities could try to implement, and this is the list they came up with. I'm looking for help on these three, so I can show off JRuby's potential and give whoever implements the best example a nice plug and a t-shirt.

So let me repeat that as a call to action: Help implement these and the ones chosen for the session will earn a t-shirt and a plug on stage by me. Fair enough?

Here's the list:

#1 - Client Application

Write a simple, read-only Twitter client as a desktop app.
The Twitter API is documented at
User provides twitter email address and password , then browses friends and their statuses.
User can also filter content based on plain text or a regexp. (Our users are geeks.)
Your choice whether to use the JSON or XML output from Twitter.

#2 - Web Application

As a database, we'll use the "world" sample database from MySQL (
The Web Application lets a user browse countries, sorting them using different criteria (e.g. population or GNP), and select cities and display them on a map using one of the many map widgets around, e.g. Google (
For geocoding you could use e.g.

#3 - Free round

Up to you. Show us something your language can do better than any other! But again, be concise.

So obviously #1 would be a GUI thing, probably using one of the frameworks available for JRuby. And #2 is going to be a Rails app. At the moment, I think any of Jeremy Ashkenas's ruby-processing demos would be an easy add for the script-bowl, but if anyone wants to try to top them go for it. I'd especially like to see something JavaFX-like, with nice vector-drawn graphics and maybe a physics model. Make it pretty. Sound is good :)

Feel free to email me directly, but the JRuby user mailing list would probably be a better place to do it so we can all see it and discuss the entries that represent the best of JRuby.

Ruby Implementers Design Meeting #1

On Monday evening, the various Ruby implementers (sans John Lam since he had a schedule conflict) got together on FreeNode IRC in #ruby-core to discuss various design and future-related agenda items.

Here's the agenda and IRC log, and here's a rundown of what was discussed.

Class and Module Constant Scoping

Evan Phoenix had the first item, a question about the behavior of constant scoping in classes versus modules. For example, the following snipit:

class A; end
class B; end
A::B # will find B above, but print a warning

module C; end
module D; end
C::D # will complain it can't find C::D

The reason for this is that the :: operator only searches the class hierarchy for constants. So in A::B, only A and its superclasses get searched. Since this includes Object, and B is defined at the top level, A::B finds B. But since this is probably not the behavior the user wanted, given that they were explicitly scoping the lookup to B, a warning is printed. By the same logic, C::D does not find the top-level D, because modules do not have superclasses.

Evan made the point that if the "class fallthrough" behavior is warned against, perhaps it is intended to be removed or deprecated. Though there was some discussion about the issue, it was mostly tabled and we decided it should be discussed at length on the ruby-core mailing list if there's anything more to discuss. I suspect it won't come up again.

Multiple VM Support Discussion

As you may know, Sun Microsystems and the Univesity of Tokyo are collaborating on a Multiple-VM specification and implementation for Ruby. The primary folks involved are me, Tom Enebo, and Koichi Sasada, creator of the Ruby 1.9 VM (YARV). So this agenda item was mine.

Largely, the MVM situation looks like this:
  • JRuby already has fairly complete and production-ready MVM support, since each JRuby runtime is "just an object" and you can have as many active as you like. But we lack a formal API and have no explicit APIs for cross-VM communication and control. The JRuby MVM support is how we're able to run multiple Rails instances in a single JVM, something no other implementation has achieved.
  • Rubinius has a simple implementation of MVM, with a standard API and support for cross-VM communication and control. But largely, nobody's using it, and like the rest of Rubinius it's not "production ready".
  • Ruby 1.9 (YARV) has neither support for MVM nor any API prepared to host it. The bulk of the work then would ultimately fall on Koichi and the ruby-core folks to both implement MVM and implement the APIs we decide upon to support it.

So the discussion largely focused on APIs and what we want them to do. In general, most folks agreed that sub-VMs should be largely independent from one another, but have a simple communication mechanism. While pipes were suggested, most agreed they were too low-level and would lead to each program implementing their own "wire protocol" unnecessarily. The model Rubinius takes is to allow passing messages of only integral types: String, Symbol, Numeric, Array, and Hash. I strongly prefer this model over the low-level pipe version and over anything more complex, since more complicated protocols can easily be built upon it. Rubinius also does this as fully asynchronous message passing, though it's unclear whether that would be a requirement of the MVM API or not. We also mostly agreed that if "forking" a VM in-process were ever to be supported, it would come after the first round of work on MVM. As far as I'm concerned, fork needs to die a flaming death RSN.

We closed out this item by getting the MVM list and wiki information out to people and encouraging more discussion. Hopefully this one will pick up a bit; I'd really love to put a standard API face on JRuby's excellent MVM support.

RubySpec and ruby-core

The final two agenda items we covered mostly focused on the RubySpec specs and how we can get the ruby-core folks to use them, contribute to them, and otherwise bless them as some sort of "official" specification effort. Brian Ford started out with an overview of the spec status, how they're run, where they're being used. Currently JRuby, IronRuby, and Rubinius all use the specs, though only JRuby and Rubinius developers are actively contributing back to it. The ruby-core team expressed some concerns. Will this mean replacing Ruby's existing test/ dir? How easy is it to run the specs? Do they require features we have changed/are changing in 1.9/2.0? Can we host them in the Ruby repository?

In general the discussion we very productive. One by one we tried to address their concerns, and I think we made a great case for them to start using and contributing to the specs. They were also interested in getting a list of spec failures we'd seen against Ruby 1.8.7pre2 (Vladimir handled my action item for that...thanks Vladimir!), and I suggested that Brian write up a simple "how to" to send to ruby-core, so they'd all understand the process and how it's supposed to work. I think we're getting very close to having ruby-core use and bless the specs as being a required part of Ruby development. And that's just fine with me.

Next Meeting

We scheduled the next meeting for the same time (9PM CDT, 11:00JST) on Apr 30/May 1. Here's the current agenda for the next ruby design meeting