JRuby enters the home stretch for Rails support
Posted by rick February 01, 2007 @ 02:12 AM
We’re on the home stretch now, and Rails is getting more and more solid every day. With you all helping, we should be able to finish off the remaining failures, clean up major outstanding JRuby issues, and kick out a pretty sweet “Rails-supporting” JRuby release in the next couple weeks. —Charles Nutter
I’m not a Java guy by any means, but I don’t think anyone disagrees that this is great news. Why? The idea of dynamic languages on the JVM is very appealing, even Ryan Tomayko thinks so.
Now, being a recovering C# programmer, I had no idea how to get JRuby installed and running. So, here’s a quick newbie guide for you Mac OSX users. If you have good instructions for other platforms beyond what’s in the JRuby blog, please post or link to them in the comments. Also, be sure to use the proper reporting channels for any bugs you come across: the Rails Trac for Rails bugs, and JRuby’s JIRA for JRuby issues.
- First, you need java. Luckily, it happens to ship with Tiger. “java -version” tells me I have v1.5.0_06. Awesome.
- I actually set this up over the weekend, and used ‘ant test’ to build and test JRuby. This required me to install JUnit to proceed. I just created a directory to act as my CLASSPATH, and threw junit-4.1.jar in there.
- Set up a few environment variables (see below for the list).
- Add /path/to/jruby/bin to your PATH.
export CLASSPATH=/path/to/junit-4.1.jar
export JRUBY_HOME=/path/to/jruby
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home
export JRUBY_SHELL=/bin/zsh
After this was done, I was able to run jruby or jirb directly. Depending on where you add the jruby/bin path, you may or may not be using the JRuby gem script or not. Use ‘which gem’ to check.
There you go, you should be all ready to help the JRuby folks out.
Could someone explain why it is useful to run ruby code on the JVM other than for legacy integration reasons? Or is that the reason?
-The JVM could end up being a very fast environment in which to run Ruby.
-Access to loads of good Java libraries
-Freeing all the Java workers (I used to be one) to work in a language that is more fun.
Another VM supporting Ruby is always a good thing. For one thing It means businesses will be more open to using Ruby. There is no need to install another interpreter if you already have Java, which many do.
It allows for closer integration with java apps, which again is attractive to folk who run a lot of java already.
Deployment. Using something like Glassfish and wab files could standardise deployment in simple cases.
Finally, having multiple VMs knocking about means a greater push to documenting Ruby implementations and in general more momentum developing VM/interpreter performance and improving the language in general.
Hi everyone, I just registered at this site this week.
I’m sorry for being so lazy, but I wanted to ask if anyone could point me to any threads that I should have a read of first, so I can get involved here?
Thanks! Michael
I’ve installed jruby per the instructions but I don’t understand how rails knows to use the jruby vm? Do you not have to modify your rails app so that it doesn’t use the standard ruby interpreter?
Michael,
I haven’t tried it yet but I guess you just have to start the script/server command using the jruby interpreter. So something like
jruby script/server
in your Rails app’s directory should do the trick. As I said I haven’t tried it yet, but I will… :)
Are there already significant performance improvements?
Does this mean that a Rails application can be compiled to a bytecode and distributed as a “binary” without the need to distribute source?
This is one thing missing from Ruby/Rails (to my knowledge). It would be nice if there were something similar to the Zend encoder.
From Nutter’s article
“I’ve seen things in Rails code no man should have to see”
Ouch, any guesses to where that code lies?
Building and setting up JRuby was a breeze, but in the few benchmarks I ran (adding numbers, creating regexps), JRuby was 2-20X slower than plain Ruby, not counting Java startup. I know these trivial benchmarks don’t indicate real performance, but are these results normal?
Krishna: Yes, those numbers are typical for the moment. Currently JRuby runs only in interpreted mode, and it’s still slower than Ruby for most operations. However we’re working hard to bring interpreted mode up to Ruby performance, and we have a compiled under development that shows great promise for exceeding Ruby performance. We had an emphasis on correctness before performance up until a couple months ago, but since we started working on performance we’ve doubled or tripled it over this past summer’s release. So we’re making great progress, never fear!
Jake: Yes, that will be possible eventually. Currently the compiler only handles a very small subset of Ruby, but it’s developing quickly. Hopefully by this summer, it will be possible to compile a whole Rails app.
Paul: I was being a bit humorous, but the Rails code is filled with some pretty crazy Ruby stuff. If I hadn’t been spending the past two years working on a Ruby implementation I’d have a really hard time understanding it.
Michael: Just use “jruby” instead of “ruby” when you run things. And scripts installed into <jruby home>/bin should all use JRuby instead by default.
I’m sure this is great for a number of reasons. The one that sticks out to me the most at the moment is how JRuby could be embedded in AOLServer. That seems in theory to be a badass combination.