JRuby

32 bit jruby cannot run with 64 bit JVM installed

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Testcase included:
    yes
  • Number of attachments :
    0

Description

c:\>java -version
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b22)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)

c:\>jruby -v
Cannot find Java 1.5 or higher.

Dunno if this is a bug or not, but would be nice to be able to go back and forth.

Something else may be going on here, as well:

after installing the "64 bit" 1.7.0.preview1, I get this (when running from a 32-bit console2):

c:\jruby-1.7.0.preview1\bin>java -version
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b22)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)

c:\jruby-1.7.0.preview1\bin>jruby -v
Cannot find Java 1.5 or higher.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Roger Pack added a comment -

work around: set JAVA_HOME environment variable, like $ set JAVA_HOME=c:\Program Files\Java\jre6
then you can run 64 bit jruby, or use it with jre7 on windows.

Show
Roger Pack added a comment - work around: set JAVA_HOME environment variable, like $ set JAVA_HOME=c:\Program Files\Java\jre6 then you can run 64 bit jruby, or use it with jre7 on windows.
Hide
Permalink
Charles Oliver Nutter added a comment -

All our 32/64-bit installers do is install the JRE for that bittage and try to rig up JRuby to use it. I'm not sure how Windows might be monkeying with JRE/JVM selection at boot time.

We might be shipping a different jruby.exe binary in the two versions (I don't remember), which could lead to 32-bit not being able to load 64-bit...but that may not possible to fix, since Windows does not support universal binaries (i.e. I'm not sure it's possible for us to ship a single jruby.exe that would work with both 32 and 64-bit JVMs). I say "may not be possible" because if our 32-bit binary is just launching a 64-bit process, that would probably be ok.

Can you be a little more specific about what is actually conflicting here? I'm confused.

Show
Charles Oliver Nutter added a comment - All our 32/64-bit installers do is install the JRE for that bittage and try to rig up JRuby to use it. I'm not sure how Windows might be monkeying with JRE/JVM selection at boot time. We might be shipping a different jruby.exe binary in the two versions (I don't remember), which could lead to 32-bit not being able to load 64-bit...but that may not possible to fix, since Windows does not support universal binaries (i.e. I'm not sure it's possible for us to ship a single jruby.exe that would work with both 32 and 64-bit JVMs). I say "may not be possible" because if our 32-bit binary is just launching a 64-bit process, that would probably be ok. Can you be a little more specific about what is actually conflicting here? I'm confused.
Hide
Permalink
Roger Pack added a comment -

It appears that jruby.exe uses the following:
if JAVA_HOME is set, use JAVA_HOME\bin\java
else use c:\windows\system32\java (it might use c:\windows\system\java too)
else fail.

I think it should probably also use "any java on the path" as another step before failing.

Show
Roger Pack added a comment - It appears that jruby.exe uses the following: if JAVA_HOME is set, use JAVA_HOME\bin\java else use c:\windows\system32\java (it might use c:\windows\system\java too) else fail. I think it should probably also use "any java on the path" as another step before failing.
Hide
Permalink
Charles Oliver Nutter added a comment -

Yeah, I think you're right.

Show
Charles Oliver Nutter added a comment - Yeah, I think you're right.
Hide
Permalink
Per Lundberg added a comment -

For me, just setting JAVA_HOME didn't work. But what did work is to point it at a JDK (not a JRE).

Show
Per Lundberg added a comment - For me, just setting JAVA_HOME didn't work. But what did work is to point it at a JDK (not a JRE).

People

  • Assignee:
    Thomas E Enebo
    Reporter:
    Roger Pack
Vote (0)
Watch (4)

Dates

  • Created:
    Updated: