Hacker News

WASM on the JVM Ships Under the Bytecode Alliance

37 points by dustingetz ago | 7 comments

zimmi |next [-]

Do I understand correctly that endive ships with a garbage collector and only uses the host gc when references pass over the API boundary? I don't know much about wasm, but would it be possible to use the host gc for everything? Or is there some inherent property of wasm that makes this impossible / less efficient?

pjmlp |root |parent [-]

In general, it depends on which features a language runtime needs from a GC, for example, currently the WASM GC proposal is unusable for languages that need internal pointers, thus languages like C# keep shipping their own.

fwsgonzo |next |previous [-]

Is this going to be a way to execute emscripted-built projects locally? Or is the target something else entirely, like WASM interacting with Java?

cchianel |root |parent [-]

Think of WASM as a kinda universal library target. You can compile C, Rust, C#, Java to WASM, and then you can use it in a different language from the source. This way, Java can run C or Rust code without going through a FFI (foreign function interface). From the article, one example is porting tree-sitter (a C library) to Java by first compiling it to WASM, then use Endive to access its function.

As an example of how it can be used, you can look at https://github.com/Christopher-Chianelli/timefold-wasm-servi... and https://github.com/Christopher-Chianelli/timefold-wasm-c-cli..., which was an experiment I did to try using C code inside Timefold Solver (a Java library that can be used to solve constraint problems like Employee Scheduling and Vehicle Routing).

iberator |previous [-]

Usecases?

naruhodo |root |parent [-]

The use case appears to be Java applications that rely on native libraries. Instead of a Java rewrite or using JNI or similar, Endive gives a new deployment model for native libraries (whether the language is garbage-collected or has manual memory-management) as a regular JAR file [1]:

> You didn't install a native binary. You didn't configure JNI. You didn't cross-compile anything for your target platform. It just works, because the Wasm module is hiding inside a regular JAR on your classpath.

> WebAssembly changes this equation. Take a proven C or Rust library, compile it to Wasm, and run it within JVM boundaries. You keep everything the JVM gives you: guaranteed memory safety, fault isolation, platform independence, advanced JIT, observability, and the "write once, run anywhere" promise. The Wasm module becomes just another artifact inside your JAR, an implementation detail that your users never need to think about.

And from TFA[2]:

> The previous article focused on wrapping C and Rust libraries. Those languages compile to Wasm straightforwardly because they manage their own memory. But a growing number of languages target the WasmGC proposal instead: Kotlin/Wasm, Dart, and others. Google Sheets already runs its Java-based calculation engine through WasmGC in production. Endive passes the full WasmGC spec testsuite

[1] https://foojay.io/today/a-new-generation-of-java-libraries-i...

[2] https://foojay.io/today/endive-1-0-wasm/