In 2012 and beyond you really want to be using Ruby 1.9 syntax (as per the standard ruby implementation KRI). JRuby 1.6 uses Ruby 1.8 syntax by default, but this can be changed to be 1.9. There are a bevy of different ways to do this. I’ll outline these here, and give you my recommendation on what to do.
Command Line parameter
The first way to set the ruby syntax version is to call ruby with a –1.9 parameter thusly:
This I don’t like at all because it doesn’t work with irb, and you have to type different things when using KRI and JRuby.
RUBYOPT Environment variable
A second option is to set the RUBYOPT environment variable to –1.9
This works for irb, but will actually prevent KRI from starting up as KRI doesn’t support the –1.9 parameter (KRI is Ruby 1.9 so the parameter doesn’t make sense).
JRUBY_OPTS Environment variable
Another option is to set the JRUBY_OPTS environment variable.
This works great for JRuby , irb in JRuby, and KRI.
.jrubyrc file
The next useful option is in a user specific .jrubyrc file. This gets called before JRuby starts up. Keep it in ~/.jrubyrc
This works well if you are working in an environment where you will always be running 1.9 compatible code. It’s what I currently do.
rvm
If you are using rvm there are a number of ways to do things.
First you can use a .rvmrc and set the JRUBY_OPTS variable, or a PROJECT_JRUBY_OPTS environment variable.
The second option is to enable rvm jruby hooks.
hooks live in $rvm_path/hooks.
In rvm 1.14.3 there are a series of after_use hooks, including some after_use_jruby hooks. Inspect these to see what they do (after_use runs all the other after_use hooks, and the after_use_jruby scripts will get some JRuby magic happening). You could put one of the earlier options here to help make JRuby work.
Conclusion
In conclusion my recommendations for getting JRuby 1.6 to use Ruby 1.9 syntax are:
- use a .jrubyrc file wherever possible
- use a .rvmrc for situations where you need different versions of JRuby.
Related posts:










“export RUBYOPT=”–1.9″” is quite horrible you’re right and slightly annoying to find.
Hopefully most developers are using bundler to control their gem dependencies, and luckily, bundler now supports the feature of blowing up if the ruby environment isn’t set correctly.
http://gembundler.com/v1.2/gemfile_ruby.html
Hopefully this solves a few issues that creep in when having shared environments!