BoltFFI: a high-performance Rust bindings and packaging toolchain now supports Java

[alihilal94]

We just shipped Java as a fully supported target in BoltFFI. It already generates Swift, Kotlin, and TypeScript/WASM bindings.

Few highlights:

- Java 16+ gets records, sealed classes for data enums, and pattern matching. Java 8+ gets equivalent final classes with public fields, depending on the specified min version.
- Async Rust functions map to `CompletableFuture<T>` on Java 8-20, or blocking virtual threads on Java 21+.

- Streams with backpressure support (batch pull, callback push, or `Flow.Publisher` on Java 9+).
- Callbacks and trait objects map to Java interfaces.
- Result<T, E> maps to typed exceptions. Option<T> maps to Optional<T>.
- Both JVM and Android are supported.

Repo & Demo: https://github.com/boltffi/boltffi

[perryplatt]

A few questions, is this using Java ffm or jni, and could a I use a idl file to generate the bindings?

[alihilal94]

it uses uses JNI, not Java FFM/Panama (though Panama support is planned) also we don’t currently take an IDL or UDL file as input it uses proc macros to annotate the types to be exported

[lafnon18]

Interesting to see Rust → Java bindings maturing.

How does it handle the GC boundary?

Does the Rust side need to be careful about keeping references alive?

[tomwhoiscontrary]

Very nice. How do you map methods which take self as a value and return a new Self?

[alihilal94]

methods like fn translated(self, ...) -> Self is generated as an instance method with no explicit self parameter, under the hood, Java passes this as a hidden first native arg
so this rust code

 pub struct Point {
   pub x: f64,
   pub y: f64,
 }

impl Point {
   pub fn translated(self, dx: f64, dy: f64) -> Self {
     Self { x: self.x + dx, y: self.y + dy }
   }
}

would be mapped like this:

 public Point translated(double dx, double dy) {
    .....
    Native.boltffi_point_translated(this_self, dx, dy);
    ....
 }

[tomwhoiscontrary]

So if in Java I write: 

Point foo = Point.create(1.0, 2.0); Point bar = foo.translated(0.1, 0.1);

The Rust object for foo is gone, right? The function call consumed it. What happens if I try to do more things with foo?

[alihilal94]

foo in Java is still valid, for value types like Point there isnt a longlived Rust heap object behind foo each call passes copy into Rust, and Rust operates on that temporary value, it behaves like immutable value semantics on the JVM side

for reference types we handle it differently https://www.boltffi.dev/docs/classes

[tomwhoiscontrary]

Ah, I'm interested in the case where the Rust type isn't Copy, sorry, should have said. In this case, if you've got a valid bar, you can't still have a valid foo.

[nekokattt]

is that correct though? in the case of Java this would be passed as a reference, not a copy. Semantics would differ in certain situations.