JRuby cannot find JAVA_HOME when option -w is used w/ JRE

I just tried the same thing on a Windows XP computer and cannot reproduce the error, so it might be specific to Windows Vista.

D:\> set JAVA_HOME
JAVA_HOME=C:\Program Files\Java\jre7

D:\> jruby -v
jruby 1.7.0 (1.9.3p203) 2012-10-22 ff1ebbe on Java HotSpot(TM) Client VM 1.7.0_0
9-b05 [Windows XP-x86]

D:\> jruby -e "puts 'a'"
a

D:\> jruby -w -e "puts 'a'"
a

The problem still exists with JRuby 1.7.1. However, further testing revealed that the order of options is important:

C:\>set JAVA_HOME
JAVA_HOME=C:\Program Files\Java\jre7

C:\>jruby -e "puts 'a'"
a

C:\>jruby -w -e "puts 'a'"
Cannot locate Java installation, specified by JAVA_HOME:


C:\>jruby -e "puts 'a'" -w
a

C:\>

I also noticed that the problem is the same if option "-v" is used.

Confirmed on my machine...this is pretty weird

Claus, master of jruby has updated windows binaries with a fix. There is something really strange in C++ where I think a std::string was taking ownership of the char * we used as a base for searching for JVM homes. A particular method would erase some strings and since the pointers ownership changed it was also erasing the our base search string.

tbh, I am unclear why this solves the problem as described other than noticing it was making a string "" which shouldn't be. Once I fixed this all seemed to be well though. Could you please confirm your problem has been resolved?

To answer another nagging question: This was a regression. I updated to a new g++ and that required some code changes to even compile. The outcome was something else involving perhaps? std::string overload for '=' involving a const char *? I would have only claimed to know C++ with any reasonable knowledge about 20 years ago, so the more complicated stdlib gets the most lost I get now.

Thomas, looking here http://ci.jruby.org/snapshots/master/ the newest binary is from 19-Feb-2013. Am I looking in the wrong place?

If you have a clone from our git repository: https://github.com/jruby/jruby you can get them without building. I am not sure why latest nightly has not produced them. You can also grab them from githib.com if you just want to get the binaries are try them in an existing installation:

https://github.com/jruby/jruby/blob/master/bin/jruby.exe
https://github.com/jruby/jruby/blob/master/bin/jrubyw.exe
https://github.com/jruby/jruby/blob/master/bin/jruby.dll

and install these into an existing JRuby installation.

I have now tested the new version of the launcher on two computers running Windows Vista and Windows 7. The problem was present before installing the new launcher and gone after installing it.

Great based on that I am resolving this one. Thanks for testing and I just released JRuby 1.7.3 so the new launcher is in there and ready to go.

I think this fix is working around the problem described in JRUBY-7096 – the stack is being corrupted in PlatformLauncher::checkJDKHome. The corrupt stack causes the random behaviour noted in this bug.

By introducing a new stack variable in this fix, I believe the corruption has shifted around and it's not producing the same problem but the underlying corruption is still there.