21–30 of 45 posts
I thought JNI was being deprecated in favor of the new FFM interface. https://openjdk.org/jeps/472
> It is not a goal to deprecate JNI or to remove JNI from the Java Platform.
It says they want to put a safety barrier in front of JNI, so you'll have to explicitly indicate that you want a module to use JNI.
I agree that Java + native is the way to go. But does rust really give you an edge over C/C++? Here is how you do JNI with C++: http://move.rupy.se/file/jvm.txt So simple it's ridiculous! Then you can use RegisterNatives to give C++ API to the Java side instead of the stub (Java calls C++ .dll/.so) thing...
That is the systems language most JVM implementations make use of, alongside Java, and what is directly supported by JNI tooling, including on Java IDEs mixed language debugging.
And in what concerns Java, native is anyway the synonym for unsafe.
However to each their own.
I found mixing Bun and Rust works pretty well. Bun has gotten many cool new things recently which feel great to use and it has a nice FFI API. So I have Next.js apps running in Bun runtime and anything CPU bound is written in Rust and called via FFI.
I found mixing Bun and Rust works pretty well. Bun has gotten many cool new things recently which feel great to use and it has a nice FFI API. So I have Next.js apps running in Bun runtime and anything CPU bound is written in Rust and called via FFI.
I would have expected Zig, given Bun, or using Deno instead, if Rust as extension language.
You can use Zig instead if it meets your needs, but last time I checked, the Zig ecosystem was lacking compared to Rust.
> or using Deno instead, if Rust as extension language
Deno? There was a thread the other day that Deno is dead. I wouldn't even compare Deno and Bun because Bun is just waaay better. Even before Bun already felt very polished and nice to use, and now it even has native postgres and s3 clients. And it doesn't try to sell you a KV database or some shit.
Earlier quoted context omitted.
I would have expected Zig, given Bun, or using Deno instead, if Rust as extension language.
> I would have expected Zig You can use Zig instead if it meets your needs, but last time I checked, the Zig ecosystem was lacking compared to Rust. > or using Deno instead, if Rust as extension language Deno? There was a thread the other day that Deno is dead. I wouldn't even compare Deno and Bun because Bun is just waaay better. Even before Bun already felt very polished and nice to use, and now it even has native…
Earlier quoted context omitted.
> I would have expected Zig You can use Zig instead if it meets your needs, but last time I checked, the Zig ecosystem was lacking compared to Rust. > or using Deno instead, if Rust as extension language Deno? There was a thread the other day that Deno is dead. I wouldn't even compare Deno and Bun because Bun is just waaay better. Even before Bun already felt very polished and nice to use, and now it even has native…
The point I was making was using the same language the VM makes use of, instead of adding extra layers.
I thought JNI was being deprecated in favor of the new FFM interface. https://openjdk.org/jeps/472
1. The article seems kind-of shallow. I didn't see any concrete (qualitative or quantitative) remarks about the "fast" part. I don't doubt you have reasons to do this - but I expected some information on what component are you writing using Rust + JNI, and how it helped? Or is it just a demo? At some point, repeated calls into the JNI are counter-productive to performance, since the JIT can not optimize them. Pinning…
This article summarizes our experience from a commercial project that runs on an in-vehicle Android system. In this project, we needed to invoke Rust code(DB) from Java(App), so we couldn't directly use the project’s source code for demonstration. Instead, we created a demo project: https://github.com/GreptimeTeam/rust-java-demo 1. I agree that using Rust doesn't necessarily mean faster performance; it simply gives y…
5. How did you handle java local and global ref lifetimes in rust callee? Was it assumed that java caller owns all the refs and freed after the rust computation returns? Or did your calls mostly involve byte buffers and primitive types? That latter is a sweet spot but not always feasible.
I found mixing Bun and Rust works pretty well. Bun has gotten many cool new things recently which feel great to use and it has a nice FFI API. So I have Next.js apps running in Bun runtime and anything CPU bound is written in Rust and called via FFI.
I thought JNI was being deprecated in favor of the new FFM interface. https://openjdk.org/jeps/472
This says: > It is not a goal to deprecate JNI or to remove JNI from the Java Platform. It says they want to put a safety barrier in front of JNI, so you'll have to explicitly indicate that you want a module to use JNI.
That's one of the reasons I posted it. A lot of knowledgeable people here can chime in more details. And a sibling comment did!