Add java support (using JNA) #857

fredszaq · 2023-07-21T15:38:44Z

This builds on #853 and adds a new language backend capable of generating java bindings.

The generated bindings use JNA (I used the last version 5.13.0 while developing but this will probably work with earlier ones as well)

Most of the new code lives in bindgen/language_backend/java_jna.rs and is pretty straightforward generation as most on the complicated things were done in the previous refactoring.

The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibility to put a configuration file specific to a language alongside the standard one and the test will take this one instead of the default one if it exists (quite a few test use the header config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P)

All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developing and they worked as expected.

fredszaq · 2023-09-07T12:54:07Z

rebased with the changes from #853

coolbluewater · 2024-03-12T04:49:27Z

@fredszaq very cool! Currently I hand-author a Kotlin bridge class, e.g.:

package com.foo.bar
import android.view.Surface
class RustBridge {
    init { System.loadLibrary("mylibrary") }
    external fun enterFrame(rustObj: Long)
}

and use the following Rust code with the 'jni_fn' attribute to ensure the name is correct:

#[no_mangle]
#[jni_fn("com.foo.bar.RustBridge")]
pub fn enterFrame(_env: *mut JNIEnv, _: JClass, obj: jlong) {
    let obj = unsafe { &mut *(obj as *mut WgpuCanvas) };
    obj.enter_frame();
}

Will your backend be able to generate the kotlin bindings for this type? Also, will it handle the rust name conversion without needing the jni_fn crate?
Thanks!

fredszaq · 2024-03-12T11:03:56Z

Hi @coolbluewater ! The generated bindings use JNA. JNA works a bit differently than JNI (which your example uses) even though JNA uses JNI under the hood.

When using JNI, the native code needs to be aware that it is called by a JVM. This is done for rust via the #[jni_fn()] proc macro.

When using JNA, the native code doesn't need to be aware it is called from a JVM, as JNA is able to work with plain C compatible symbols. This means you don't have to have specific symbols for your lib for it to be able to be loaded from the jvm.

This means the rust code would probably look something like that

#[no_mangle]
pub fn enterFrame(obj: *mut WgpuCanvas) {
   unsafe{ obj.enterFrame}
}

and the koltin code would look like that

class RustBridge {
    fun enterFrame(rustObj: MyLib.WgpuCanvasByReference) {
         MyLib.INSTANCE.entrerFrame(rustObj)
    }
}

With the code for the class MyLib beeing generated.

You can configure the name and the package of the generated class (actually the public api is an interface) in cbingen's config

[java_jna]
package = "my.package"
interface_name = "MyLib"

coolbluewater · 2024-03-12T18:54:03Z

@fredszaq thanks for your response!
I need the JNIEnv and also need to pass jobjects from Kotlin to Rust.
Is this possible in some way?

fredszaq · 2024-03-13T13:26:40Z

Not sure you want to mix JNI and JNA as the approaches are different and I'm not sure you'll be able to get access to the JNIEnv via JNA.

Writing a java-jni language backend that expects the rust code to be JNI aware could be a solution if you really need to access the JNIEnv/jobjects from the rust code. The the java-jna language backend in this PR kinda expects you are using plain old C compatible symbols.

This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.

fredszaq · 2024-04-15T10:08:35Z

@emilio I rebased this with the latest master, following the merge of #942

src/bindgen/config.rs

emilio · 2024-04-15T15:36:58Z

src/bindgen/config.rs

 deserialize_enum_str!(Language);

 impl Language {
    pub(crate) fn typedef(self) -> &'static str {
        match self {
            Language::Cxx | Language::C => "typedef",
            Language::Cython => "ctypedef",
+            _ => unimplemented!(),


Let's list JNA explicitly. But why can't it hit it?

this typedef function is only used by the enum code

emilio · 2024-04-15T15:37:53Z

src/bindgen/ir/enumeration.rs

@@ -721,6 +721,7 @@ impl Enum {
                    write!(out, "{}enum {}", config.style.cython_def(), tag_name);
                }
            }
+            _ => unimplemented!(),


Same, let's at least keep the language listed. But why can't it be reached? Worth a comment.

This code is really C (and derivatives) oriented, even though it lives in the IR, the impl of enums for java ends up not using this at all

src/bindgen/language_backend/java_jna.rs

emilio · 2024-04-15T15:47:25Z

src/bindgen/language_backend/java_jna.rs

+                            IntKind::B8 => "byte",
+                            IntKind::B16 => "short",
+                            IntKind::B32 => "int",
+                            IntKind::B64 => "long",


Also not right, this doesn't seem guaranteed to be 64 bytes.

long is 64 bytes in java

emilio · 2024-04-15T15:47:50Z

src/bindgen/language_backend/java_jna.rs

+            IntKind::B8 => JnaIntegerType::Byte,
+            IntKind::B16 => JnaIntegerType::Short,
+            IntKind::B32 => JnaIntegerType::Int,
+            IntKind::B64 => JnaIntegerType::Long,


Also not right.

emilio · 2024-04-15T15:48:04Z

src/bindgen/language_backend/java_jna.rs

+            IntKind::Short => JnaIntegerType::Short,
+            IntKind::Int => JnaIntegerType::Int,
+            IntKind::Long => JnaIntegerType::NativeLong,
+            IntKind::LongLong => JnaIntegerType::Long,


LongLong is not Long, for sure.

Long is 64 bytes in java (the C long is NativeLong)

fredszaq mentioned this pull request Jul 21, 2023

Support C# and/or expose intermediate representation? #846

Open

fredszaq force-pushed the java-jna-backend branch from 12e10bf to 2f48952 Compare July 21, 2023 16:04

fredszaq mentioned this pull request Aug 17, 2023

Support for custom languages #867

Draft

fredszaq force-pushed the java-jna-backend branch from d8b3cfa to 23313a2 Compare September 7, 2023 12:51

fredszaq force-pushed the java-jna-backend branch 2 times, most recently from 23df5f2 to a9b2175 Compare October 4, 2023 12:35

fredszaq force-pushed the java-jna-backend branch from a9b2175 to dde67d2 Compare November 17, 2023 11:12

fredszaq mentioned this pull request Jan 24, 2024

Introduce language backend #853

Closed

fredszaq force-pushed the java-jna-backend branch from dde67d2 to 83874a5 Compare February 5, 2024 11:03

fredszaq force-pushed the java-jna-backend branch from 83874a5 to c463fea Compare March 12, 2024 12:52

fredszaq mentioned this pull request Apr 14, 2024

Language back-end #942

Merged

fredszaq force-pushed the java-jna-backend branch from c463fea to 8f7cbfa Compare April 15, 2024 10:02

emilio requested changes Apr 15, 2024

View reviewed changes

fredszaq added 2 commits April 16, 2024 17:23

address review comments

6d6470b

clippy

043a569

fredszaq requested a review from emilio April 24, 2024 20:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add java support (using JNA) #857

Add java support (using JNA) #857

fredszaq commented Jul 21, 2023

fredszaq commented Sep 7, 2023

coolbluewater commented Mar 12, 2024 •

edited

fredszaq commented Mar 12, 2024

coolbluewater commented Mar 12, 2024

fredszaq commented Mar 13, 2024

fredszaq commented Apr 15, 2024

emilio Apr 15, 2024

fredszaq Apr 16, 2024

emilio Apr 15, 2024

fredszaq Apr 16, 2024

emilio Apr 15, 2024

fredszaq Apr 16, 2024

emilio Apr 15, 2024

emilio Apr 15, 2024

fredszaq Apr 16, 2024

Add java support (using JNA) #857

Are you sure you want to change the base?

Add java support (using JNA) #857

Conversation

fredszaq commented Jul 21, 2023

fredszaq commented Sep 7, 2023

coolbluewater commented Mar 12, 2024 • edited

fredszaq commented Mar 12, 2024

coolbluewater commented Mar 12, 2024

fredszaq commented Mar 13, 2024

fredszaq commented Apr 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coolbluewater commented Mar 12, 2024 •

edited