Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
jreznik at redhat.com
Wed Jan 16 13:05:23 UTC 2013
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/JRuby 1.7 =
* Detailed description:
Transition to JRuby 1.7 will consist of 3 basic steps:
- Updating packages
Most of the packages that JRuby depends on are in Fedora just because of JRuby,
so they can be safely updated.
Some dependencies are shared with other packages, so they will have to be
discussed with their owners (see #Scope).
- Integration with Fedora
Normally, each Ruby implementations ships with its own copy of RubyGems
library. This is wrong because a) it's bundling, b) there is no reason
why multiple Ruby implementations wouldn't be able to share one RubyGems
library. There used to be some differencies in JRuby's copy of RubyGems,
but the JRuby upstream has been very cooperative and managed to get them
all merged into upstream RubyGems.
The integration will require changing Fedora's operating_system.rb (place
for distro-specific defaults for RubyGems). This change will result into
all Gems with binary extensions having to be recompiled, as the binary
extension placement will change. See  for current operating_system.rb
look and its changes from F18.
What should "/usr/bin/ruby" point to? During standard Gem packaging process,
the executable files in Gems get shebangs according to the binary that they
are packaged with (Ruby => "/usr/bin/ruby"; JRuby => "/usr/bin/jruby").
Therefore executing a Ruby "binary" runs the interpreter that was used for
building (or the hardcoded one, which is usually Ruby). Using alternatives
for "/usr/bin/ruby" doesn't seem to be a very good option, because Ruby and
JRuby are not in fact full alternatives, as they for example cannot use same
extension Gems (but it still makes sense to allow executing same binaries
with them). Also, alternatives are only switchable on admin level (we want
every developer with non-root privileges to be able to choose the
interpreter). Therefore Ruby-SIG has come up with solution of having
"/usr/bin/ruby" as a bash script (currently called rubypick) , that
allows user to choose the interpreter as first argument on invocation
(_mri_ or _jruby_), if such a parameter is present. Otherwise it falls
back to a default. For example invoking "ruby_binary _jruby_ --foo=bar"
in fact invokes "/usr/bin/jruby ruby_binary --foo=bar". This bash script
will be in a separate package and both Ruby and JRuby will depend on it.
Ruby-SIG knows that this feature might be controversial and we wouldn't
want it to stop us from bringing JRuby's power to Fedora (if met with a
heavy resistance). So if anyone will suggest a more suitable solution,
we'll go with it instead of this one.
- Changes in packaging
None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of
the box, but packaging of Gems with JRuby extensions is turning out to be
very complicated, so the guidelines for it will be postponed to next release
(as well as the actual packaging). Users will be still able to install Gems
with JRuby extensions, both system-wide (into /usr/local/) and into their
More information about the devel-announce