this post was submitted on 14 May 2024
64 points (91.0% liked)

Rust

5974 readers
98 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
 

I thought this might interest you Rust folk. This is kinda like an LLVM bitcode to JVM bytecode translator. So run rustc with --emit=llvm-ir (I think that's the flag) and then pass the bitcode image to this program, then get JVM bytecode which you can make a JVM bytecode archive (JAR) from it. Could be an interesting? The author says it can JVM code from Clang output, so why not Rustc?

Keep in mind that these are two different beasts, JVM is designed for a safe virtual machine and LLVM is chiefly used to be translated into machine code. However, stupider and more wonderful things have been done with LLVM and JVM, for example, there's an LLVM to 6502 translator, so you could be making NES games with Rust.

I will test this in a few days, busy implementing my own JVM (hope I can do it) and I don't have the Rust toolchain installed on my system. But hey maybe someone can make a Cargo plugin from it (is it possible?)

Thanks, later.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 6 months ago* (last edited 6 months ago) (1 children)

I don’t see the harm of transpiling parts of the app into JVM to access the full breadth of features

You mean apart from the 5x performance hit?

I'm unaware of anything the Android SDK supports that the NDK doesn't, and the ndk-rs crate provides bindings for it. I agree that Rust on Android is not where we'd like it to be yet, especially with regard to familiar interfaces like winit, but transpiling Rust to JVM bytecode is not the solution. Come to that, it's not the solution to any problem that currently does or (with any luck) will ever exist. Best case scenario, you shift the problem from creating bindings to the NDK to creating much uglier bindings to random Java classes through something JNI-like.

Speaking of the JNI, actually, writing Rust native code that can both be called from and call into to Java/Kotlin/other JVM code via the JNI is actually fairly straightforward.

Transpiling Rust to Java bytecode is a remarkably silly idea and I cannot fathom why anyone would ever do it, except maybe if they really cared about portability.