What environment are you running on? Using MacOS + Java 7 or Java 8 it is working on my machine:

java -cp jruby-complete-1.7.12.jar org.jruby.Main -S gem list

*** LOCAL GEMS ***

bouncy-castle-java (1.5.0147)
jruby-openssl (0.9.3)
json (1.8.0 java)
krypt (0.0.2.rc1)
krypt-core (0.0.2.rc1 universal-java)
krypt-provider-jdk (0.0.2.rc1)
rake (10.1.0)
rdoc (4.0.1)

I'm running WinXP and java 1.7.0_21. It's the same with other java versions. And with Win7 it's works well. It seems something is wrong with WinXP.

hmm weird indeed. I wonder if it is FAT filesystem vs NTFS? I don't actually have a XP system to try :|

I can try to debug it. Can you give me a hint where I can start to look?

A first thing to do would be to git clone our repo and build JRuby on XP and see if it works once you compile it (you need Maven and Javac installed). If you compile and bin\jruby -S gem list does not work then it is something more generic and related to jar-complete. I am also fairly sure we used to work on XP, so we can probably git bisect the problem if we can figure out a point where it was working on XP.

with jruby-complete-9000.dev.jar

**ERROR:  Loading command: list (NameError)
        uninitialized constant Fiddle::Pointer** 
is raised. But it seems the gem command is found, because the exception is raised from 
file:/C:/Av/jruby-master/maven/jruby-complete/target/jruby-complete-9000.dev.jar!/META-INF/jruby.home/bin/gem:1:in `(root)'
org/jruby/RubyKernel.java:862:in `load'
file:/C:/Av/jruby-master/maven/jruby-complete/target/jruby-complete-9000.dev.jar!/META-INF/jruby.home/bin/gem:4:in `(root)'

Maybe the problem is resolved with the next release.

Oh be sure to 'git co jruby-1_7' to help reduce the scope since master is for our next major release. We might be regressing on windows atm on master.

FWIW I've been using the java -cp jruby-complete.jar org.jruby.Main -S <something> for the past number of releases (13 onward) in jruby-gradle with great success.

Perhaps this bug has been fixed?

@rtyler (and others) actually it is still broken:

$ java -jar maven/jruby-complete/target/jruby-complete-1.7.17-SNAPSHOT.jar -S gem list
SyntaxError: /home/christian/.rbenv/shims/gem:3: syntax error, unexpected tSTRING_BEG
[ -n "$RBENV_DEBUG" ] && set -x
     ^

the reason is that -S search on path and finds those shims from "rbenv" which are not ruby files but shell scripts and it fails.

I would say given "preference" to the bundled scripts would at least solve part of the rbenv problem and make tools like "jruby-gradle" more robust against what is installed on machine it running on.

not sure if I just reported a "new bug"

see also #1218

@mkristian it sounds like you've got a different bug than what the original reporter had/ I've seen the same behavior that you're discussing with rvm and its setting of GEM_HOME and GEM_PATH and the likes. I think the current behavior in JRuby is correct in respecting those values however.

java -jar -Djruby.cli.debug=true target/jruby-complete-9.2.1.0-SNAPSHOT.jar -S gem list

*** LOCAL GEMS ***

bundler (1.16.1)
bundler-unload (1.0.2)
cmath (default: 1.0.0)
csv (default: 1.0.0)
executable-hooks (1.3.2)
fileutils (default: 1.1.0)
gem-wrappers (1.4.0)
ipaddr (default: 1.2.0)
jar-dependencies (default: 0.3.12)
jruby-launcher (1.1.4 java)
jruby-openssl (default: 0.10.0 java, 0.9.21 java)
jruby-readline (default: 1.2.2 java)
json (default: 2.1.0 java)
psych (default: 3.0.2 java)
rake (12.3.0)
rake-ant (default: 1.0.4)
rdoc (default: 6.0.1)
rubygems-bundler (1.4.4)
rvm (1.11.3.9)
scanf (default: 1.0.0)
webrick (default: 1.4.2)

... working well these days