JRuby

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

supercedes

Bug - A problem which impairs or prevents the functions of the product. JRUBY-5736 error: "Unsupported platform: unknown-darwin" when using JRuby's ffi and Java 1.7 macosx-port build

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Hiro Asari added a comment -

I reverted the previous commit.

Show
Hiro Asari added a comment - I reverted the previous commit.
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: