Nowadays there are several decent Ruby runtimes available besides MRI ranging from alpha-versions to production-ready status. Using RVM these different interpreters become more and more interchangeable.
h2. current problems
Since switching between runtimes became as easy _rvm use x_ more care has to be taken to support a wide range of interpreters and versions. This is especially true for shared code like gems.
Some engines like JRuby have limitations that prevent the usage of some Ruby features. In most cases it’s possible to work around these limitations and provide a different solution that works, but might be somewhat less performant.
h2. checking runtimes
Ruby is great at introspection, but especially 1.8 misses some key information like _RUBY_ENGINE_ to determine the current interpreter at runtime and one has to extract it from the _RUBY_DESCRIPTION_ constant.
WhichRuby aims at simplifying this tedious task and providing a simple API:
# irb@jruby jruby-1.4.0 > require 'which_ruby' => true jruby-1.4.0 > include WhichRuby => Object jruby-1.4.0 > jruby? => true
Executing different code fragments becomes as easy as defining a scope:
ruby_scope(:jruby) do # custom jruby code here end
This comes in very handy for stuff like accessing Java code natively via JRuby instead of using RJB.
I don’t like Rubbae – I love it!