Wednesday, April 19, 2006

JRuby on Rails

After seeing David Heinemeier Hansson ask the "Groovy on Rails" project not to use that moniker (since it isn't Ruby, it isn't Rails, and it has a completely separate codebase), I figured I'd play it safe and ask him directly whether "JRuby on Rails" would be acceptable. We intend to run Rails unmodified, and we're trying to be as "Ruby" as possible, so it seemed to me that since JRuby on Rails is the same under the covers, the extra "J" wasn't that big a deal. David agreed:


As long as Rails remains virtually unaltered and fully functional, I suppose JRuby on Rails isn't too bad. I'm a tad protective of the term Ruby on Rails, though, and I want to make sure that there's no confusion about what it refers to. But I can't immediately see any confusion points here.

So the JRuby on Rails name should stick, and we have cautious approval from the Rails creator himself to use it. Huzzah!

5 comments:

Anonymous said...

I know this is probably too forward thinking and/or pretentious, but do you think that eventually Rails apps could be deployed on Tomcat packaged as WAR files?

Charles Oliver Nutter said...

That is exactly the deployment scenario we're shooting for. We already have some prototype code of a "CGI Servlet" that provides a webapp-based entry point into Rails, and it works as well as an FCGI option (with the caveat that we're still much slower than C Ruby). Eventually, we want to be able to WAR up an entire Rails app + libraries, shove it into a webapp container, and off it goes. It will happen sooner than you think!

Anthony Martin said...

I saw in the limitations document that the reason you can't extend with Ruby in runtime and consume the descendant with Java because you don't have a compiler.

This might be over my head, but if you did have a compiler, wouldn't that make JRuby an excellent platform for testing Ruby code? An intriguing possibility.

Or is this compiler a pie-in-the-sky requirement in the first place?

Charles Oliver Nutter said...

We are planning to start work on a compiler after JavaOne, both for performance reasons and to support extending Java classes in Ruby (which we can't do now because we use java.lang.reflect.Proxy which only works on interfaces). We may also have an intermediate compiler for a short-term performance gain, and we may be able to tackle the class extension issue earlier than compilation. Fun stuff!

Anthony Martin said...

Well, I'm very impressed. I'll be tracking developments on this.