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

        Hide
        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
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated: