6 ms·

"The object model of RubyMotion for Android is based on Java. Ruby classes, objects, methods and exceptions are Java classes, objects, methods, and exceptions,

"The object model of RubyMotion for Android is based on Java. Ruby classes, objects, methods and exceptions are Java classes, objects, methods, and exceptions, and vice-versa. No bridge is involved." But then later it says "The runtime uses the Java Native Interface (JNI) in order to integrate with Java". And then later it says, "RubyMotion Android apps are fully compiled into optimized machine code, exactly like their iOS and OS X counterparts." Does any of this make any sense? They seem to be contradicting themselves left and right on the same page.

thezoid 12y ago
I believe you don't need to do anything along the lines of JRuby where you would sometimes need to bridge libraries from Java-land into Ruby. This most likely makes the same assumption that you are using a similar kind of project management as in RubyMotion for iOS and using RM specific libraries.
- bratsche 12y ago
  I've never had the opportunity to bridge Java-to-Ruby for JRuby. But when I read "the runtime uses JNI", I read that as a bridge. And when they start off with "Ruby classes are Java classes", then later say "everything is compiled to native" that seems like more double-speak.
jballanc 12y ago
"Runtime" generally refers to the library routines that handle the creating and keeping track of objects, adding methods and/or ivars to those objects, and calling methods. How you call those library routines can vary. In a traditional JVM implementation, a class-file will compile down to bytecode, and the bytecode interpreter turns the relevant ops into calls to the runtime routines. JNI provides another way to call the runtime routines (using C++ calling conventions), and for the runtime to call back into your code. So, for example, if you have a method that adds two numbers together defined on the Foo class, then you want to instantiate that class and call that method from your app, you would compile the "add two numbers" method down to machine code. You'd pass the location of the compiled method to the runtime, registering it with the Foo class, using JNI. Then you'd compile your app code (that will instantiate the class and call the method) to machine code with instructions to set up the stack and jump to the JNI routines to instantiate the class and finally call the method. Make sense?
stusmall 12y ago
That jumped out to me too. There is a significant performance hit when you make JNI calls. Last I looked not all of Android's API are easily exposed to native code. Constantly context switching from native to managed can be beastly. I'd be curious on how often and when it is doing these JNI calls, what is native and what is java.
- crashandburn4 12y ago
  Sorry when you say native versus Java what do you mean? As far as I was concerned all native apps are java?
  - girvo 12y ago
    Native machine code, he means, rather than "native to Android" Java bytecode.
  - icebraining 12y ago
    https://developer.android.com/tools/sdk/ndk/index.html https://developer.android.com/tools/sdk/ndk/index.html

thezoid 12y ago

I believe you don't need to do anything along the lines of JRuby where you would sometimes need to bridge libraries from Java-land into Ruby. This most likely makes the same assumption that you are using a similar kind of project management as in RubyMotion for iOS and using RM specific libraries.

bratsche 12y ago
I've never had the opportunity to bridge Java-to-Ruby for JRuby. But when I read "the runtime uses JNI", I read that as a bridge. And when they start off with "Ruby classes are Java classes", then later say "everything is compiled to native" that seems like more double-speak.

jballanc 12y ago

"Runtime" generally refers to the library routines that handle the creating and keeping track of objects, adding methods and/or ivars to those objects, and calling methods. How you call those library routines can vary. In a traditional JVM implementation, a class-file will compile down to bytecode, and the bytecode interpreter turns the relevant ops into calls to the runtime routines. JNI provides another way to call the runtime routines (using C++ calling conventions), and for the runtime to call back into your code. So, for example, if you have a method that adds two numbers together defined on the Foo class, then you want to instantiate that class and call that method from your app, you would compile the "add two numbers" method down to machine code. You'd pass the location of the compiled method to the runtime, registering it with the Foo class, using JNI. Then you'd compile your app code (that will instantiate the class and call the method) to machine code with instructions to set up the stack and jump to the JNI routines to instantiate the class and finally call the method. Make sense?

stusmall 12y ago

That jumped out to me too. There is a significant performance hit when you make JNI calls. Last I looked not all of Android's API are easily exposed to native code. Constantly context switching from native to managed can be beastly. I'd be curious on how often and when it is doing these JNI calls, what is native and what is java.

crashandburn4 12y ago
Sorry when you say native versus Java what do you mean? As far as I was concerned all native apps are java?
- girvo 12y ago
  Native machine code, he means, rather than "native to Android" Java bytecode.
- icebraining 12y ago
  https://developer.android.com/tools/sdk/ndk/index.html https://developer.android.com/tools/sdk/ndk/index.html