JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-5737

error: "Unsupported platform: unknown-darwin" when using JRuby's ffi and Java 1.7 macosx-port build

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.6.2
    • Fix Version/s: JRuby 1.6.4
    • Component/s: Core Classes/Modules
    • Labels:
      None
    • Environment:
      jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-25 ef0212b) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-universal-java]
    • Number of attachments :
      0

      Description

      I installed jruby head using rvm using the standard Java 1.6.0

      Then using a recent build of the macosx-port Java 1.7 build:

      http://www.concord.org/~sbannasch/macosx-port/java-1.7.0-internal-macosx-port-2011-04-25.tar.gz
      Expand and copy to ~/Library/Java/JavaVirtualMachines
      Open /Applications/Utilities/Java\ Preferences.app and move OpenJDK7 to the top of the list.

      Open a new shell.

      $ java -version
      openjdk version "1.7.0-internal"
      OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_04_16_22_03-b00)
      OpenJDK 64-Bit Server VM (build 21.0-b07, mixed mode)
      
      $ ruby --version
      jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-25 ef0212b) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-universal-java]
      

      I then also installed rubygems 1.7.2 (but I don't think that matters):

      $ rvm use jruby-head
      Using /Users/stephen/.rvm/gems/jruby-head
      Running /Users/stephen/.rvm/hooks/after_use
      
      $ gem install rubygems-update
      Successfully installed rubygems-update-1.7.2
      1 gem installed
      [dev]$ update_rubygems 
      RubyGems 1.7.2 installed
      
      === 1.7.2 / 2011-04-05
      
      * 1 Bug Fix:
        * Warn on loading bad spec array values (ntlm-http gem has nil in its cert
          chain)
      
      
      ------------------------------------------------------------------------------
      
      RubyGems installed the following executables:
      	/Users/stephen/.rvm/rubies/jruby-head/bin/jgem
      

      Now install nokogiri and try and require it:

      $ gem install nokogiri
      Successfully installed nokogiri-1.4.4.2-java
      1 gem installed
      
      $ ruby -e "require 'rubygems'; require 'nokogiri'"
      LoadError: Unsupported platform: unknown-darwin
        require at org/jruby/RubyKernel.java:1038
        require at /Users/stephen/.rvm/rubies/jruby-head/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36
         (root) at /Users/stephen/.rvm/rubies/jruby-head/lib/ruby/site_ruby/shared/ffi/ffi.rb:69
        require at org/jruby/RubyKernel.java:1038
        require at /Users/stephen/.rvm/rubies/jruby-head/lib/ruby/site_ruby/shared/ffi/ffi.rb:36
         (root) at /Users/stephen/.rvm/rubies/jruby-head/lib/ruby/site_ruby/shared/ffi.rb:1
        require at org/jruby/RubyKernel.java:1038
        require at /Users/stephen/.rvm/rubies/jruby-head/lib/ruby/site_ruby/shared/ffi.rb:36
         (root) at /Users/stephen/.rvm/gems/jruby-head@xproject/gems/nokogiri-1.4.4.2-java/lib/nokogiri.rb:10
        require at org/jruby/RubyKernel.java:1038
        require at /Users/stephen/.rvm/gems/jruby-head@xproject/gems/nokogiri-1.4.4.2-java/lib/nokogiri.rb:57
         (root) at -e:1
      

      $ gem install nokogiri

        Issue Links

          Activity

          Hide
          Hiro Asari added a comment -

          This is due to the unexpected value of the os.arch property set by the JDK.

          $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")'
          java version "1.6.0_24"
          Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326)
          Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)
          "x86_64"
          
          $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")'
          openjdk version "1.7.0-internal"
          OpenJDK Runtime Environment (build 1.7.0-internal-b00)
          OpenJDK 64-Bit Server VM (build 21.0-b03, mixed mode)
          "universal"
          

          I don't know what "universal" is supposed to mean. This sounds like something to be worked out by the JDK itself.

          Show
          Hiro Asari added a comment - This is due to the unexpected value of the os.arch property set by the JDK. $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")' java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) "x86_64" $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")' openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-b00) OpenJDK 64-Bit Server VM (build 21.0-b03, mixed mode) "universal" I don't know what "universal" is supposed to mean. This sounds like something to be worked out by the JDK itself.
          Hide
          Stephen Bannasch added a comment -

          In this case universal means that that it includes both i386 and x86_64 builds.

          See this thread about the Mac OS/X Port data Model on the macosx-port-de mailing list:

          http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-January/000017.html

          Obviously at some point there are separate i386 and x86_64 libs in the macosx bundle.

          If you installed the build in ~/Library/Java/JavaVirtualMachines then when you open up teh Java Prefs app you'll see both 64-bit and 32-bit OpenJDK7 builds listed.

          FYI: here's the announcement for the OpenJDK for Mac OS X source repository, mailing list, project home – lots of useful links:

          http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-January/000007.html

          Show
          Stephen Bannasch added a comment - In this case universal means that that it includes both i386 and x86_64 builds. See this thread about the Mac OS/X Port data Model on the macosx-port-de mailing list: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-January/000017.html Obviously at some point there are separate i386 and x86_64 libs in the macosx bundle. If you installed the build in ~/Library/Java/JavaVirtualMachines then when you open up teh Java Prefs app you'll see both 64-bit and 32-bit OpenJDK7 builds listed. FYI: here's the announcement for the OpenJDK for Mac OS X source repository, mailing list, project home – lots of useful links: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-January/000007.html
          Hide
          Hiro Asari added a comment -

          Thanks for the information.

          Fixed in trunk: https://github.com/jruby/jruby/commit/69e3739b3aa1245560443bc2473c70d61a397926

          by adding "universal" as an accepted value for os.arch.

          FFI still won't load on the trunk, though, since FFI doesn't support "universal" yet. We should open a separate ticket for that.

          Show
          Hiro Asari added a comment - Thanks for the information. Fixed in trunk: https://github.com/jruby/jruby/commit/69e3739b3aa1245560443bc2473c70d61a397926 by adding "universal" as an accepted value for os.arch . FFI still won't load on the trunk, though, since FFI doesn't support "universal" yet. We should open a separate ticket for that.
          Hide
          Wayne Meissner added a comment -

          I'm not entirely happy with that change. There are parts of FFI code that need to know exactly what the arch is, and whilst this change may let the FFI subsystem load, it is likely to crash and burn soon after.

          Show
          Wayne Meissner added a comment - I'm not entirely happy with that change. There are parts of FFI code that need to know exactly what the arch is, and whilst this change may let the FFI subsystem load, it is likely to crash and burn soon after.
          Hide
          Hiro Asari added a comment -

          Wayne,

          As I mentioned, this ticket is for loading FFI. My intention was to address the actual functionality in JRUBY-5738.

          Show
          Hiro Asari added a comment - Wayne, As I mentioned, this ticket is for loading FFI. My intention was to address the actual functionality in JRUBY-5738 .
          Hide
          Stephen Bannasch added a comment -

          I'm happy to bring this up on the macosx-port list – while the actual build is universal the actual code that runs is not universal – normally you specify which which arch you want to use – either in the Java preferences app or perhaps also on the command line.

          I'm not certain that responding with 'universal' is the correct response for the macos-port OpenJDK 1.7 build.

          Show
          Stephen Bannasch added a comment - I'm happy to bring this up on the macosx-port list – while the actual build is universal the actual code that runs is not universal – normally you specify which which arch you want to use – either in the Java preferences app or perhaps also on the command line. I'm not certain that responding with 'universal' is the correct response for the macos-port OpenJDK 1.7 build.
          Hide
          Charles Oliver Nutter added a comment -

          My opinion here is that the macosx-port should present the same version/platform/arch that Apple's JDK does. The universal fix might be a good enough patch for now, since at least it lets things load (Stephen: perhaps you can confirm all FFI stuff of yours is working with this patch), but ideally we shouldn't need any changes to support macosx-port versions.

          I believe they are wrong to not have the actual architecture in os.arch. Who wants to make our case to them?

          Also, I believe this fix will break FFI when the "universal" JVM we're running on is actually in 32-bit mode. It will also fail to load jffi native backend and FFI libraries that have bit-specific versions.

          Show
          Charles Oliver Nutter added a comment - My opinion here is that the macosx-port should present the same version/platform/arch that Apple's JDK does. The universal fix might be a good enough patch for now, since at least it lets things load (Stephen: perhaps you can confirm all FFI stuff of yours is working with this patch), but ideally we shouldn't need any changes to support macosx-port versions. I believe they are wrong to not have the actual architecture in os.arch. Who wants to make our case to them? Also, I believe this fix will break FFI when the "universal" JVM we're running on is actually in 32-bit mode. It will also fail to load jffi native backend and FFI libraries that have bit-specific versions.
          Hide
          Charles Oliver Nutter added a comment -

          Fuel for the fire:

          ~/projects/jruby ➔ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']"
          jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-27 27dca93) (Java HotSpot(TM) Client VM 1.6.0_22) [darwin-i386-java]
          "i386"
          
          ~/projects/jruby ➔ jruby -v -e "p ENV_JAVA['os.arch']"
          jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-27 27dca93) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_22) [darwin-x86_64-java]
          "x86_64"
          
          ~/projects/jruby ➔ pickjdk
           1) 1.6.0_22-b04-307.jdk < CURRENT
           2) 1.7.0-stephen-2011_04_04.jdk
           3) 1.7.0.jdk
           4) None
          Choose one of the above [1-4]: 3
          New JDK: 1.7.0.jdk
          
          ~/projects/jruby &#10132; jruby -v -J-d32 -e "p ENV_JAVA['os.arch']"
          jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-27 27dca93) (OpenJDK Server VM 1.7.0-internal) [darwin-universal-java]
          "universal"
          
          ~/projects/jruby &#10132; jruby -v -e "p ENV_JAVA['os.arch']"
          jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-27 27dca93) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-universal-java]
          "universal"
          
          Show
          Charles Oliver Nutter added a comment - Fuel for the fire: ~/projects/jruby &#10132; jruby -v -J-d32 -e "p ENV_JAVA['os.arch']" jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-27 27dca93) (Java HotSpot(TM) Client VM 1.6.0_22) [darwin-i386-java] "i386" ~/projects/jruby &#10132; jruby -v -e "p ENV_JAVA['os.arch']" jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-27 27dca93) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_22) [darwin-x86_64-java] "x86_64" ~/projects/jruby &#10132; pickjdk 1) 1.6.0_22-b04-307.jdk < CURRENT 2) 1.7.0-stephen-2011_04_04.jdk 3) 1.7.0.jdk 4) None Choose one of the above [1-4]: 3 New JDK: 1.7.0.jdk ~/projects/jruby &#10132; jruby -v -J-d32 -e "p ENV_JAVA['os.arch']" jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-27 27dca93) (OpenJDK Server VM 1.7.0-internal) [darwin-universal-java] "universal" ~/projects/jruby &#10132; jruby -v -e "p ENV_JAVA['os.arch']" jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-27 27dca93) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-universal-java] "universal"
          Hide
          Stephen Bannasch added a comment -

          I asked about this on the macosx-port-de mailing list and Mike Swingler says it shouldn't respond with 'universal' as an arch

          http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-April/000391.html

          I added a bug report here: http://java.net/jira/browse/MACOSX_PORT-37

          Show
          Stephen Bannasch added a comment - I asked about this on the macosx-port-de mailing list and Mike Swingler says it shouldn't respond with 'universal' as an arch http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-April/000391.html I added a bug report here: http://java.net/jira/browse/MACOSX_PORT-37
          Hide
          Hiro Asari added a comment -

          I reverted the previous commit.

          Show
          Hiro Asari added a comment - I reverted the previous commit.
          Hide
          Charles Oliver Nutter added a comment -

          Stephen: Thank you for looking into it. Looks like they'll patch it and we'll get a working build from them at some point.

          You might let them know that currently sun.arch.data.model does appear to be working...so if they assume the OS X OpenJDK is only running on x86, they could use the same logic to select i386 or x86_64:

          ~/projects/jruby &#10132; pickjdk 3
          New JDK: 1.7.0.jdk
          
          ~/projects/jruby &#10132; jruby -e "p ENV_JAVA['sun.arch.data.model']"
          "64"
          
          ~/projects/jruby &#10132; jruby -J-d32 -e "p ENV_JAVA['sun.arch.data.model']"
          "32"
          

          This might also be a reasonable workaround to commit to master, i.e. "universal" indicates we should use sun.arch.data.model to select the appropriate x86 arch. At least we'd work until they patch it then.

          Show
          Charles Oliver Nutter added a comment - Stephen: Thank you for looking into it. Looks like they'll patch it and we'll get a working build from them at some point. You might let them know that currently sun.arch.data.model does appear to be working...so if they assume the OS X OpenJDK is only running on x86, they could use the same logic to select i386 or x86_64: ~/projects/jruby &#10132; pickjdk 3 New JDK: 1.7.0.jdk ~/projects/jruby &#10132; jruby -e "p ENV_JAVA['sun.arch.data.model']" "64" ~/projects/jruby &#10132; jruby -J-d32 -e "p ENV_JAVA['sun.arch.data.model']" "32" This might also be a reasonable workaround to commit to master, i.e. "universal" indicates we should use sun.arch.data.model to select the appropriate x86 arch. At least we'd work until they patch it then.
          Hide
          Stephen Bannasch added a comment -

          I just built the latest mlvm and os.arch returns: "amd64"

          $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")'
          openjdk version "1.7.0-internal"
          OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_04_29_09_40-b00)
          OpenJDK 64-Bit Server VM (build 21.0-b07, mixed mode)
          "amd64"
          

          Latest mlvm:
          http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-mlvm-2011_04_29.tar.gz

          Show
          Stephen Bannasch added a comment - I just built the latest mlvm and os.arch returns: "amd64" $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")' openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_04_29_09_40-b00) OpenJDK 64-Bit Server VM (build 21.0-b07, mixed mode) "amd64" Latest mlvm: http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-mlvm-2011_04_29.tar.gz
          Hide
          Stephen Bannasch added a comment -

          Also get the same arch from the latest bsd-port build:

          $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")'
          openjdk version "1.7.0-internal"
          OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_04_29_12_02-b00)
          OpenJDK 64-Bit Server VM (build 21.0-b09, mixed mode)
          "amd64"
          
          Show
          Stephen Bannasch added a comment - Also get the same arch from the latest bsd-port build: $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")' openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_04_29_12_02-b00) OpenJDK 64-Bit Server VM (build 21.0-b09, mixed mode) "amd64"
          Hide
          Hiro Asari added a comment -

          amd64 and x86_64 are equivalent as far as JRuby is concerned.

          Show
          Hiro Asari added a comment - amd64 and x86_64 are equivalent as far as JRuby is concerned.
          Hide
          Charles Oliver Nutter added a comment -

          FWIW, I merged a hacky fix for this in 804b21c8f6b068b574b2ed931c6b5ce86eb23ab2 (and f93084e3d2c0d3b50f63671c0a36bbd311a7382b on jruby-1_6 branch; will be in 1.6.2) that uses the data.model property to determine the correct arch. It's good enough for now.

          Show
          Charles Oliver Nutter added a comment - FWIW, I merged a hacky fix for this in 804b21c8f6b068b574b2ed931c6b5ce86eb23ab2 (and f93084e3d2c0d3b50f63671c0a36bbd311a7382b on jruby-1_6 branch; will be in 1.6.2) that uses the data.model property to determine the correct arch. It's good enough for now.
          Hide
          Stephen Bannasch added a comment -

          astrange resolved http://java.net/jira/browse/MACOSX_PORT-37 but now getting the arch from JRuby head doesn't work at all.

          First installed jruby-head with rvm, next testing with MacOS X system Java and then with the latest macosx-port build

          $ java -version
          java version "1.6.0_24"
          Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326)
          Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)
          
          $ rvm use jruby-head
          Using /Users/stephen/.rvm/gems/jruby-head
          Running /Users/stephen/.rvm/hooks/after_use
          
          $ jruby -v
          jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java]
          
          $ jruby -v -e "p ENV_JAVA['os.arch']"
          jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java]
          "x86_64"
          
          $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']"
          jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (Java HotSpot(TM) Client VM 1.6.0_24) [darwin-i386-java]
          "i386"
          
          $ java -version
          openjdk version "1.7.0-internal"
          OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_06_13_21_31-b00)
          OpenJDK 64-Bit Server VM (build 21.0-b15, mixed mode)
          
          $ jruby -v -e "p ENV_JAVA['os.arch']"
          jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java]
          InvokeDynamicSupport.java:435:in `invocationFallback': java.lang.invoke.WrongMethodTypeException: (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/String;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject; cannot be called with a different arity as ([Ljava/lang/Object;)Ljava/lang/Object;
          	from -e:1:in `__file__'
          	from -e:-1:in `load'
          	from Ruby.java:675:in `runScript'
          	from Ruby.java:579:in `runNormally'
          	from Ruby.java:428:in `runFromMain'
          	from Main.java:278:in `doRunFromMain'
          	from Main.java:198:in `internalRun'
          	from Main.java:164:in `run'
          	from Main.java:148:in `run'
          	from Main.java:128:in `main'
          
          $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']"
          jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (OpenJDK Server VM 1.7.0-internal) [darwin-i386-java]
          InvokeDynamicSupport.java:435:in `invocationFallback': java.lang.invoke.WrongMethodTypeException: (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/String;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject; cannot be called with a different arity as ([Ljava/lang/Object;)Ljava/lang/Object;
          	from -e:1:in `__file__'
          	from -e:-1:in `load'
          	from Ruby.java:675:in `runScript'
          	from Ruby.java:579:in `runNormally'
          	from Ruby.java:428:in `runFromMain'
          	from Main.java:278:in `doRunFromMain'
          	from Main.java:198:in `internalRun'
          	from Main.java:164:in `run'
          	from Main.java:148:in `run'
          	from Main.java:128:in `main'
          
          $ jruby -rjava -e 'p java.lang.System.getProperty("os.arch")'
          LoadError: load error: builtin/java/org.jruby.ast -- java.lang.invoke.WrongMethodTypeException: (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/String;)Lorg/jruby/runtime/builtin/IRubyObject; cannot be called with a different arity as ([Ljava/lang/Object;)Ljava/lang/Object;
            require at org/jruby/RubyKernel.java:1039
          
          Show
          Stephen Bannasch added a comment - astrange resolved http://java.net/jira/browse/MACOSX_PORT-37 but now getting the arch from JRuby head doesn't work at all. First installed jruby-head with rvm, next testing with MacOS X system Java and then with the latest macosx-port build $ java -version java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) $ rvm use jruby-head Using /Users/stephen/.rvm/gems/jruby-head Running /Users/stephen/.rvm/hooks/after_use $ jruby -v jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java] $ jruby -v -e "p ENV_JAVA['os.arch']" jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java] "x86_64" $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']" jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (Java HotSpot(TM) Client VM 1.6.0_24) [darwin-i386-java] "i386" $ java -version openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_06_13_21_31-b00) OpenJDK 64-Bit Server VM (build 21.0-b15, mixed mode) $ jruby -v -e "p ENV_JAVA['os.arch']" jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java] InvokeDynamicSupport.java:435:in `invocationFallback': java.lang.invoke.WrongMethodTypeException: (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/ String ;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject; cannot be called with a different arity as ([Ljava/lang/ Object ;)Ljava/lang/ Object ; from -e:1:in `__file__' from -e:-1:in `load' from Ruby.java:675:in `runScript' from Ruby.java:579:in `runNormally' from Ruby.java:428:in `runFromMain' from Main.java:278:in `doRunFromMain' from Main.java:198:in `internalRun' from Main.java:164:in `run' from Main.java:148:in `run' from Main.java:128:in `main' $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']" jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-13 d11a1bb) (OpenJDK Server VM 1.7.0-internal) [darwin-i386-java] InvokeDynamicSupport.java:435:in `invocationFallback': java.lang.invoke.WrongMethodTypeException: (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/ String ;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject; cannot be called with a different arity as ([Ljava/lang/ Object ;)Ljava/lang/ Object ; from -e:1:in `__file__' from -e:-1:in `load' from Ruby.java:675:in `runScript' from Ruby.java:579:in `runNormally' from Ruby.java:428:in `runFromMain' from Main.java:278:in `doRunFromMain' from Main.java:198:in `internalRun' from Main.java:164:in `run' from Main.java:148:in `run' from Main.java:128:in `main' $ jruby -rjava -e 'p java.lang. System .getProperty( "os.arch" )' LoadError: load error: builtin/java/org.jruby.ast -- java.lang.invoke.WrongMethodTypeException: (Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;Ljava/lang/ String ;)Lorg/jruby/runtime/builtin/IRubyObject; cannot be called with a different arity as ([Ljava/lang/ Object ;)Ljava/lang/ Object ; require at org/jruby/RubyKernel.java:1039
          Hide
          Stephen Bannasch added a comment -

          Probably a bad interaction with the fix from Charles because it works with JRuby 1.6.2:

          $ rvm use jruby-1.6.2
          
          $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")'
          java version "1.6.0_24"
          Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326)
          Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)
          "x86_64"
          
          $ jruby -v -e "p ENV_JAVA['os.arch']"
          jruby 1.6.2 (ruby-1.8.7-p330) (2011-05-23 e2ea975) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java]
          "x86_64"
          
          $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']"
          jruby 1.6.2 (ruby-1.8.7-p330) (2011-05-23 e2ea975) (Java HotSpot(TM) Client VM 1.6.0_24) [darwin-i386-java]
          "i386"
          
          $ java -version
          openjdk version "1.7.0-internal"
          OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_06_13_21_31-b00)
          OpenJDK 64-Bit Server VM (build 21.0-b15, mixed mode)
          
          $ java -version; jruby -rjava -e 'p java.lang.System.getProperty("os.arch")'
          openjdk version "1.7.0-internal"
          OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_06_13_21_31-b00)
          OpenJDK 64-Bit Server VM (build 21.0-b15, mixed mode)
          "x86_64"
          
          $ jruby -v -e "p ENV_JAVA['os.arch']"
          jruby 1.6.2 (ruby-1.8.7-p330) (2011-05-23 e2ea975) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java]
          "x86_64"
          
          $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']"
          jruby 1.6.2 (ruby-1.8.7-p330) (2011-05-23 e2ea975) (OpenJDK Server VM 1.7.0-internal) [darwin-i386-java]
          "i386"
          
          Show
          Stephen Bannasch added a comment - Probably a bad interaction with the fix from Charles because it works with JRuby 1.6.2: $ rvm use jruby-1.6.2 $ java -version; jruby -rjava -e 'p java.lang. System .getProperty( "os.arch" )' java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) "x86_64" $ jruby -v -e "p ENV_JAVA['os.arch']" jruby 1.6.2 (ruby-1.8.7-p330) (2011-05-23 e2ea975) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java] "x86_64" $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']" jruby 1.6.2 (ruby-1.8.7-p330) (2011-05-23 e2ea975) (Java HotSpot(TM) Client VM 1.6.0_24) [darwin-i386-java] "i386" $ java -version openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_06_13_21_31-b00) OpenJDK 64-Bit Server VM (build 21.0-b15, mixed mode) $ java -version; jruby -rjava -e 'p java.lang. System .getProperty( "os.arch" )' openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_06_13_21_31-b00) OpenJDK 64-Bit Server VM (build 21.0-b15, mixed mode) "x86_64" $ jruby -v -e "p ENV_JAVA['os.arch']" jruby 1.6.2 (ruby-1.8.7-p330) (2011-05-23 e2ea975) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java] "x86_64" $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']" jruby 1.6.2 (ruby-1.8.7-p330) (2011-05-23 e2ea975) (OpenJDK Server VM 1.7.0-internal) [darwin-i386-java] "i386"
          Hide
          Hiro Asari added a comment -

          Stephen,

          Can you tell if http://code.google.com/p/openjdk-osx-build/downloads/detail?name=OpenJDK-OSX-1.7-universal-20110614.dmg has the fix? I suspect it does.

          Here's what I get:

          $ jruby -v -e "p ENV_JAVA['os.arch']"
          jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-18 cd8b796) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java]
          "x86_64"
          $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']"
          jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-18 cd8b796) (OpenJDK Server VM 1.7.0-internal) [darwin-i386-java]
          "i386"
          

          Thoughts?

          Show
          Hiro Asari added a comment - Stephen, Can you tell if http://code.google.com/p/openjdk-osx-build/downloads/detail?name=OpenJDK-OSX-1.7-universal-20110614.dmg has the fix? I suspect it does. Here's what I get: $ jruby -v -e "p ENV_JAVA['os.arch']" jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-18 cd8b796) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java] "x86_64" $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']" jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-06-18 cd8b796) (OpenJDK Server VM 1.7.0-internal) [darwin-i386-java] "i386" Thoughts?
          Hide
          Stephen Bannasch added a comment -

          Won't be able to check until tonight but looking at the results you got I'd say, yes it has the fix.

          Show
          Stephen Bannasch added a comment - Won't be able to check until tonight but looking at the results you got I'd say, yes it has the fix.
          Hide
          Wayne Meissner added a comment -

          btw, I pushed some changes into jffi a while ago to use the native lib to detect the cpu on macosx - if anyone wants to try that with jruby on JDK7, please do so - https://github.com/wmeissner/jffi

          It tries to be lazy about determining the CPU, so hopefully code that uses Platform, but does not interrogate the cpu type, won't load the stub lib.

          JRuby's Platform.java should be refactored to call down to jffi's version for system info.

          Show
          Wayne Meissner added a comment - btw, I pushed some changes into jffi a while ago to use the native lib to detect the cpu on macosx - if anyone wants to try that with jruby on JDK7, please do so - https://github.com/wmeissner/jffi It tries to be lazy about determining the CPU, so hopefully code that uses Platform, but does not interrogate the cpu type, won't load the stub lib. JRuby's Platform.java should be refactored to call down to jffi's version for system info.
          Hide
          Stephen Bannasch added a comment -

          I just tried jruby-head with a build today of macosx-port Java 1.7.0 and things seem to work.

          $ java -version
          openjdk version "1.7.0-internal"
          OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_07_18_09_08-b00)
          OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)
          
          $ jruby -v -e "p ENV_JAVA['os.arch']"
          jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-07-18 c1bb372) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java]
          "x86_64"
          
          $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']"
          jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-07-18 c1bb372) (OpenJDK Server VM 1.7.0-internal) [darwin-i386-java]
          "i386"
          

          I was also able to install and run nokogiri-1.5.0-java using jruby-head and the macosx-port of Java 1.7.0

          $ gem install nokogiri
          Fetching: nokogiri-1.5.0-java.gem (100%)
          Successfully installed nokogiri-1.5.0-java
          1 gem installed
          
          $ ruby -e "require 'rubygems'; require 'nokogiri'"
          

          I did not try wmeissner/jffi – couldn't find a readme or doc for how to use it.

          Show
          Stephen Bannasch added a comment - I just tried jruby-head with a build today of macosx-port Java 1.7.0 and things seem to work. $ java -version openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2011_07_18_09_08-b00) OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) $ jruby -v -e "p ENV_JAVA['os.arch']" jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-07-18 c1bb372) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java] "x86_64" $ jruby -v -J-d32 -e "p ENV_JAVA['os.arch']" jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-07-18 c1bb372) (OpenJDK Server VM 1.7.0-internal) [darwin-i386-java] "i386" I was also able to install and run nokogiri-1.5.0-java using jruby-head and the macosx-port of Java 1.7.0 $ gem install nokogiri Fetching: nokogiri-1.5.0-java.gem (100%) Successfully installed nokogiri-1.5.0-java 1 gem installed $ ruby -e "require 'rubygems'; require 'nokogiri'" I did not try wmeissner/jffi – couldn't find a readme or doc for how to use it.
          Hide
          Hiro Asari added a comment -

          Does this need to be open? I believe it's fixed on master.

          Show
          Hiro Asari added a comment - Does this need to be open? I believe it's fixed on master.

            People

            • Assignee:
              Hiro Asari
              Reporter:
              Stephen Bannasch
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: