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!
3 comments:
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?
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!
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!
Post a Comment