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...
Your comment is exactly the reason why while I find Rust a cool language, I would be using C++ instead.
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.
C++ is a perfectly good programming language if you never make mistakes. So the problem is that of course you'll make mistakes, and the people who wrote your compiler make mistakes, and the C++ committee makes mistakes, and the language's inventor makes mistakes, if you work in a team the other team members and the tooling both also have mistakes. Other than these issues, sound choice.
You can bash C++ as much as you feel like, if it makes you happy.
I am well aware of the issues with C++'s flaws, sometimes it is easier to deal with such flaws, than adding a new layer into the C++ sandwich of debugging tools, build toolchain and IDE tooling for a given language runtime, and dragging a whole team for the ride as well.
What about removing LLVM dependency from Rust, switch to Cranelift, so that rustc isn't hindered by C++ mistakes on LLVM?
Sure, or perhaps since LLVM devs like niches so much they might decide to RIIR.
For me the big advantage of Cranelift isn't that it's written in Rust it's that they seem to have invested more into coherent semantics. I do not want to write code which is correct but is miscompiled because the compiler internal semantics are nonsense and that's a small but noticeable problem in LLVM.
You can write contorted (but safe) Rust which LLVM just plainly miscompiles, the rust layer is like "Make local variable A, and local variable B" Ok says LLVM, "and now is the address of A the same as the address of B?" "No", says LLVM those are different, not the same variable so different addresses. OK says the Rust. Now, subtract the smaller from the larger and tell me the number you got. "Zero" triumphantly proclaims LLVM having deduced that we don't need A or B so there's no need to store them anywhere, but forgotten that it promised their addresses aren't the same... Oops.
That example is silly, but it's hard to be sure how many large codebases might tickle equivalent LLVM miscompilation, which is not good.
Might be, but then don't expect any language runtime, or compiler toolchain, that is written in C++ to be taking pull requests written in Rust anytime soon, including Rust own compilers, the GCC ongoing support effort even more so, and that was my whole point.
Regardless of how easier it is to make mistakes in C++ versus Rust.
Having written a few JNI libraries in Rust (jni-rs specifically) myself, I'd argue that it catches & prevents a lot of potential mistakes when using JNI, especially regarding error handling/refs/types. I would pick using jni-rs any day over raw JNI. The simplicity of the C JNI API is also the cause of much pain when your project expands in scope.