4 ms·

Native calls to Rust code from Java code

53 points by drrb 12y ago

simmons 12y ago
Thanks for sharing this. I hadn't previously stumbled across JNA, but it seems to support Android, so maybe it would be a good way to use general-purpose Rust libraries within Android apps without writing a lot of new JNI shim code.
- tormeh 12y ago
  I wrote a driver interface once, and JNA was the only sane way of accessing native code I found.
  - MichaelGG 12y ago
    I'm sorta blown away at the complexity and overhead of making a native call in Java. Looks like this was one if the areas Microsoft was improving in Java, with J/Direct? In comparison, calling native code from the CLR is a one-line affair. Even two-way; you just pass a delegate and the runtime creates a thunk on the fly.
    - tormeh 12y ago
      A lot of the overhead is optional, I think. Lots of boilerplate, but if you know how to ask you get direct access to memory.
    - pron 12y ago
      Yes, and this was not something that demanded attention because Java originally wanted to discourage the use of native -- and platform specific -- code. So JNI was originally thought of as a bridge you build once to your legacy C code, and then move on. Recently, people have been wanting a more liberal use of native 3rd party libraries, so this issue is getting fixed with JNR[1], which will serve as the basis of Java's new FFI being developed under Project Panama[2]. [1]: https://github.com/jnr/jnr-ffi https://github.com/jnr/jnr-ffi [2]: http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/
- theyoungestgun 12y ago
  Are there any options besides JNA and multi-process shared memory (java to native through message passing of some sort)?
  - yazaddaruvala 12y ago
    If you're not sharing memory, why not just set up a local rest server?
  - Jweb_Guru 12y ago
    You can always just use a pipe if you don't require shared memory :)
- on_and_off 12y ago
  JNA bridging is not that useful in Android's context though :( . Sure, you can write some parts of your code in Rust, but anything that uses a platform API will still have to be written in Java. I would not mind to see Google replace Java by Rust coming next IO.
  - simmons 12y ago
    I was thinking more along the lines of libraries supporting protocols, formats, cryptosystems, and the like -- stuff that doesn't require interacting with the Android API. Being able to use the Android API from Rust (or any other non-Java language) is an interesting problem, though. Unfortunately, as you mention, the API is strongly tied to specific Java/Dalvik classes and methods (the stuff in framework.jar). Many of these merely proxy to backend services over Binder/AIDL, but the Binder/AIDL calls and associated data structures are subject to change. Sometimes I wish there was a standardized interface for native code to communicate directly with backend services over Binder, but that would likely create more headaches than it would fix.
    - on_and_off 12y ago
      I am not sure their are a lot of use-cases for this where there is not already a great java or c++ library. So I fear that it might not make a lot of sense to use Rust for most apps. Regarding the API, IMO a solution can only come from Google. There are good arguments in favor of replacing Java by Rust (or a Rust inspired language managed by Google) and even to rewrite the app framework foundations in order to improve the current offering. Officially, Java is the language of the platform, but that does not necessarily mean that they won't replace it in time.
tormeh 12y ago
It would be at least as important to be able to call Java from Rust. Does anyone know if that's hard?
- jbooth 12y ago
  It's probably possible to create a situation where a JVM process calls Rust code which then calls back to some Java function, if you're inclined to spend enough time hacking with JNI (is it possible to pass a function pointer out of JVM land?). But if you started as a native Rust process, there's no JVM runtime to call into, you'd need start that up first.
  - tormeh 12y ago
    Can't Rust just use the OS to start a JVM?
    - the_why_of_y 12y ago
      It's definitely possible to bootstrap the JVM in-process but there are quite some steps to it and it requires a bunch of platform dependent code to locate and load the library via LoadLibrary(jvm.dll) / dlopen(libjvm.so). IIRC the JNI functions all have C linkage so it should be easy to do from Rust.
- AntiRush 12y ago
  There's a library[1] that wraps the jni, allowing just that. I haven't tried it, but it looks featureful enough to be useful. [1] https://github.com/Monnoroch/RustJni https://github.com/Monnoroch/RustJni
  - kodablah 12y ago
    I think the continuation of this would be a neat project. The lib starts up a JVM, it would be interesting to see a macro [1] (or will probably have to be a compiler plugin [2]) to model Java objects and make it clear the ownership of memory. 1 - http://doc.rust-lang.org/0.12.0/guide.html#macros http://doc.rust-lang.org/0.12.0/guide.html#macros 2 - http://doc.rust-lang.org/0.12.0/guide-plugin.html http://doc.rust-lang.org/0.12.0/guide-plugin.html

53 points by drrb 12y ago

Thanks for sharing this. I hadn't previously stumbled across JNA, but it seems to support Android, so maybe it would be a good way to use general-purpose Rust libraries within Android apps without writing a lot of new JNI shim code.

tormeh 12y ago
I wrote a driver interface once, and JNA was the only sane way of accessing native code I found.
- MichaelGG 12y ago
  I'm sorta blown away at the complexity and overhead of making a native call in Java. Looks like this was one if the areas Microsoft was improving in Java, with J/Direct? In comparison, calling native code from the CLR is a one-line affair. Even two-way; you just pass a delegate and the runtime creates a thunk on the fly.
  - tormeh 12y ago
    A lot of the overhead is optional, I think. Lots of boilerplate, but if you know how to ask you get direct access to memory.
  - pron 12y ago
    Yes, and this was not something that demanded attention because Java originally wanted to discourage the use of native -- and platform specific -- code. So JNI was originally thought of as a bridge you build once to your legacy C code, and then move on. Recently, people have been wanting a more liberal use of native 3rd party libraries, so this issue is getting fixed with JNR[1], which will serve as the basis of Java's new FFI being developed under Project Panama[2]. [1]: https://github.com/jnr/jnr-ffi https://github.com/jnr/jnr-ffi [2]: http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/
theyoungestgun 12y ago
Are there any options besides JNA and multi-process shared memory (java to native through message passing of some sort)?
- yazaddaruvala 12y ago
  If you're not sharing memory, why not just set up a local rest server?
- Jweb_Guru 12y ago
  You can always just use a pipe if you don't require shared memory :)
on_and_off 12y ago
JNA bridging is not that useful in Android's context though :( . Sure, you can write some parts of your code in Rust, but anything that uses a platform API will still have to be written in Java. I would not mind to see Google replace Java by Rust coming next IO.
- simmons 12y ago
  I was thinking more along the lines of libraries supporting protocols, formats, cryptosystems, and the like -- stuff that doesn't require interacting with the Android API. Being able to use the Android API from Rust (or any other non-Java language) is an interesting problem, though. Unfortunately, as you mention, the API is strongly tied to specific Java/Dalvik classes and methods (the stuff in framework.jar). Many of these merely proxy to backend services over Binder/AIDL, but the Binder/AIDL calls and associated data structures are subject to change. Sometimes I wish there was a standardized interface for native code to communicate directly with backend services over Binder, but that would likely create more headaches than it would fix.
  - on_and_off 12y ago
    I am not sure their are a lot of use-cases for this where there is not already a great java or c++ library. So I fear that it might not make a lot of sense to use Rust for most apps. Regarding the API, IMO a solution can only come from Google. There are good arguments in favor of replacing Java by Rust (or a Rust inspired language managed by Google) and even to rewrite the app framework foundations in order to improve the current offering. Officially, Java is the language of the platform, but that does not necessarily mean that they won't replace it in time.

tormeh 12y ago

It would be at least as important to be able to call Java from Rust. Does anyone know if that's hard?

jbooth 12y ago
It's probably possible to create a situation where a JVM process calls Rust code which then calls back to some Java function, if you're inclined to spend enough time hacking with JNI (is it possible to pass a function pointer out of JVM land?). But if you started as a native Rust process, there's no JVM runtime to call into, you'd need start that up first.
- tormeh 12y ago
  Can't Rust just use the OS to start a JVM?
  - the_why_of_y 12y ago
    It's definitely possible to bootstrap the JVM in-process but there are quite some steps to it and it requires a bunch of platform dependent code to locate and load the library via LoadLibrary(jvm.dll) / dlopen(libjvm.so). IIRC the JNI functions all have C linkage so it should be easy to do from Rust.
AntiRush 12y ago
There's a library[1] that wraps the jni, allowing just that. I haven't tried it, but it looks featureful enough to be useful. [1] https://github.com/Monnoroch/RustJni https://github.com/Monnoroch/RustJni
- kodablah 12y ago
  I think the continuation of this would be a neat project. The lib starts up a JVM, it would be interesting to see a macro [1] (or will probably have to be a compiler plugin [2]) to model Java objects and make it clear the ownership of memory. 1 - http://doc.rust-lang.org/0.12.0/guide.html#macros http://doc.rust-lang.org/0.12.0/guide.html#macros 2 - http://doc.rust-lang.org/0.12.0/guide-plugin.html http://doc.rust-lang.org/0.12.0/guide-plugin.html