[Rubygems-developers] Questions on 1.0.0 on JRuby

Stephen Bannasch stephen.bannasch at deanbrook.org
Fri Apr 11 17:40:34 EDT 2008

At 2:42 PM -0500 4/11/08, Charles Oliver Nutter wrote:
>Charles Oliver Nutter wrote:
>> As a representative of the JRuby implementers, *I do not want it to be
>> 'jgem'*. Please change it back to 'gem' for JRuby installs.
>Hey, we've been discussing on the JRuby IRC channel a bit and I think
>there's a compromise we could reach here.
>Our issue is that we want "gem" to work to install gems as it always has.
>The 'jgem' fix is designed to provide a specific name for JRuby (and
>other names for other impls) to allow you to know which impl you're
>installing gems against.
>When RubyGems updates now, the problem is that it both installs a 'jgem'
>script and recommends that the 'gem' script be removed. That violates
>our desire to have 'gem' always work, but it's not directly because of
>'jgem' existing.
>So one possible solution seems to be for us to make our 'gem' script
>just point at/invoke 'jgem', and for rubygems to not recommend removing
>the 'gem' script. Then we can have our 'gem' script forever, RubyGems
>updating 'jgem' will still work correctly, and people that want to use
>'jgem' can still do so.
>Action items:
>JRuby: make 'gem' script just invoke 'jgem' script
>RubyGems: disable the recommendation to delete the 'gem' script

My suggestion below is based on the initial assumption that jruby (as an alternate ruby VM) is installed in a manner in which there are separate lib gem and bin directories from the standard system Ruby. In addition IF a path to JRUBY_HOME/bin is put on the PATH env variable it is only put after a path reference to any system Ruby and it's associated system bin/ directory.

I haven't seen evidence that any other install strategy for an alternate Ruby VM will work. Nobody has yet described how a shared gem repository could work reliably when native code is involved under the current implementations.

It is the responsibility of JRuby (and packagers of JRuby) to make this separation of gem, bin, and lib directories from any other installed Ruby VM the likely outcome of various install processes.

Assuming an install as described above I suggest keeping the installed gem command as 'gem' for all alternate Ruby VMs and possibly adding a jgem command to the standard system location for bin commands. The jgem command would execute:

  /path/to/jruby/bin/jruby -S gem

This way anytime you are expecting to be using MRI (or another standard system Ruby VM) typing gem will do what you expect.

To run the JRuby gem you can type:


OR if you have added JRUBY_HOME/bin to your path you can also type:

  jruby -S gem

If my conclusion about keeping separate gem, bin, and lib directories is correct for alternate Ruby VMs AND the actual installation of multiple Ruby VMs on multiple platforms can be introspected in a reliable way THEN it **might** be useful for RubyGems to refuse to upgrade itself or install a gem in a mixed repository without using some type of --force parameter.

More information about the Rubygems-developers mailing list