This issue was identified when trying to install the murmurhash3 gem, which includes native extensions, on the Windows platform using the jruby-complete JAR file as the executable. This generated an error message as follows:

C:\temp\JRuby_Test>set GEM_HOME=C:\temp\JRuby_Test\vendor\
C:\temp\JRuby_Test>set GEM_PATH=C:\temp\JRuby_Test\vendor\
C:\temp\JRuby_Test>java -jar C:\temp\JRuby_Test\jruby-complete-1.7.10.jar -S gem install murmurhash3
Building native extensions.  This could take a while...
ERROR:  Error installing murmurhash3:
        ERROR: Failed to build gem native extension.

    java -jar /C:/temp/JRuby_Test/jruby-complete-1.7.10.jar extconf.rb
Error: Unable to access jarfile /C:/temp/JRuby_Test/jruby-complete-1.7.10.jar


Gem files will remain installed in C:/temp/JRuby_Test/vendor/gems/murmurhash3-0.1.4 for inspection.
Results logged to C:/temp/JRuby_Test/vendor/gems/murmurhash3-0.1.4/ext/murmurhash3/gem_make.out

After digging in a bit, it looked like the problem was that there was an extraneous slash at the beginning of the result of the Gem.ruby singleton method call, causing the command to come out as /C:/... instead of just C:/...

I figured while I was in there, I'd extract the Gem.jar_path method and document what it's doing since it wasn't obvious to me at first glance what the "jarred_path" input string was going to look like.

Full Disclosure: I didn't run all the unit tests myself to make sure things don't break because I don't have the whole JRuby development environment set up on my machine. I did, however, manually test the specific behavior related to this change on Windows 7 using both the system-installed jruby.exe and the jruby-complete.jar file, and also on CentOS 6.5.