Introducing Surinx

In June of this year, I spent a few hours formulating a dynamic cousin to Duby. Duby, if you don't remember, is a static-typed language with Ruby's syntax and Java's type system. Duby supports all Ruby's literals, uses local type inference (only argument types *must* be declared), and runs as fast as Java (because it produces nearly identical bytecode). But with the advent of invokedynamic, Duby needed a playmate.

Enter "Juby". Juby is intended to be basically like Duby, in that it uses Java's types and Ruby's syntax. But it takes advantage of the new invokedynamic opcode to be 100% dynamic. Juby is a dynamic Duby, or perhaps a dynamic Java with Ruby syntax. It's not hard to comprehend.

But the name was a problem. Juby sounds like "Jewbie", a pejorative term for a Jewish person. So I sent out a call for names to the Twitterverse, ultimately ending up with far more names than I could choose from.

The name I have chosen, Surinx, has a simple story attached. You see, when James Gosling created Java, he originally named it "Oak", after the tree outside his window. So I followed his lead; the tree (a bush, really) outside my window is a lilac, Syringa vulgaris. The genus "Syringa" is derived from New Latin, based on a Greek word "surinx" meaning "shepherd's pipe" from the use of the Syringa plant's hollow stems to make pipes. Perhaps Surinx is building on the "hollow stem" of the JVM to produce something you can smoke (other dynamic languages) with. Combined with its cousin "Duby", we have quite a pair.

And in other news, the simple Surinx implementation of "fib" below (identical to Ruby) manages to run fib(40) in only 7 seconds on current MLVM (OpenJDK7 + invokedynamic and other tidbits), a five-fold improvement over JRuby's fastest mode (jruby --fast).

def fib(a)
  if a < 2
    a
  else
    fib(a - 1) + fib(a - 2)
  end
end

Given that JRuby has started to support invokedynamic, the solid performance of Surinx bodes very well for JRuby's future.

Please welcome Surinx to your language repertoire!

Which Deployment for JRuby on Rails?

We often get the question "which deployment option is the best for JRuby on Rails?" The truth is that it depends on what you need out of deployment.

If you have a fairly straightforward Rails app without a lot of service dependencies and a greenfield deployment target, your best bet is probably the GlassFish gem right now. It performs really well, can handle high loads and high concurrency, and automatically detects Rails' threadsafe mode, scaling better when it's turned on. I'm no longer a Sun employee, and I still think the GF gem is an outstanding piece of work. Here's my howto on GF gem + JRuby on Rails + Apache. Update: Here's information on using Capistrano with the GlassFish gem.

If you have an existing Java EE or web container like Tomcat, JBoss, GlassFish, WebLogic, or WebSphere, you want to look into Warbler. Warbler packages your application as a .war file, suitable for deployment on any of these standard servers. The Warbler wiki is the best place to learn about deploying with Warbler.

If you're looking for something that's somewhat greenfield but also needs more advanced services like scheduled asynchronous jobs, web services, and some level of EE integration, you should look at JBoss's TorqueBox, a customized JBoss specially tailored for deployment of Rack-based apps (like Rails) on JRuby.

If you're looking for a hosting provider that can take your app and make it "just work", then you should look into Engine Yard's JRuby cloud offering. We don't yet have it 100% ready to go, but it won't be long and it will be fantastic. For now you can give us some direction and input on what that hosting/cloud should look like.

All told, there's a lot of great options for JRuby deployment, and no one of them is going to be perfect for everyone. Choose wisely, and join the JRuby mailing lists if you have questions.

Return of Ruboto!

It's been a while since I was able to work on JRuby's Android support, but tonight I managed to finally circle back. And I've got something much more impressive working today: a real IRB application!



(And yes, this works just fine on the phone too)

It turned out to be incredibly easy to get this working. I'm not using any stinking plugin because they all seemed to just get in my way. So I generated a dummy application using the "android" tool, dropped the jruby jar in "libs", wrote up a quick interactive console, built and signed it, and that's all there was to it.

JRuby turns out to work very well for this sort of thing because we have an interpreter, so we can parse and execute code dynamically. Hooray for interpreted support!

I had to tweak a couple things to work around shortcomings in Android:

• I had to edit the dx tool to allow up to a 1024M heap, since JRuby's jar has a ton of stuff in it
• I had to catch and swallow an ArrayIndexOutOfBounds exception coming out of Dalvik's enum support. Bug!

This is of course a proof-of-concept. Writing full applications in Ruby isn't far behind, but we'll need a couple adjustments to JRuby to support it well:

• Ability to run 100% precompiled with no runtime code generation
• Strip out parser, interpreter, compiler, and bytecode-generation bits to shrink the jar
• Tidy up the AOT compiler and wire it into the app build process
• Generate some Ruby stub logic for the Android APIs, so they'll work well from Ruby
• Strip down the weirder and wilder Ruby features (eval, etc) to allow fastest-possible execution

I know how to do all of this.

I've pushed ruboto-irb to Github so you can check it out and play with it. I welcome contributors :)

Ruboto lives!

Update: Good news, everyone!

First, the two bugs I've encountered have both been previously reported and are due to be fixed in an upcoming Android release. They are the enum bug and the reflection bug.

Second, someone going by the handle of "Psycho" reports in the comments that the next version of the Android Scripting Environment (ASE) will include JRuby support! Of course I'm interested in more than just scripting applications with JRuby...I'd like to be able to write applications using only Ruby code, so I'll continue working on this. But JRuby support seems to be coming in from all directions.