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
> 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/