WebAssembly on the JVM: Feature Evolution, Performance, and the Transition to Endive

WebAssembly (Wasm) is increasingly being adopted across various computing environments due to its portability, security, and performance. Initially developed for browser-based applications, it now enables server-side execution of code written in languages like C, C++, and JavaScript without requiring rewrites or native libraries. Its sandboxed runtime provides memory safety and protection against vulnerabilities, making it ideal for running untrusted code. Advancements such as Wasm GC (Garbage Collection) and the component model via WASI P2/P3 allow support for high-level languages like Scala, Kotlin, and Dart, and facilitate modular application design using interface definition files.

The technology is being used in production by major CDNs for edge computing, where lightweight sandboxing supports high-density, secure workloads. It also powers use cases ranging from CPU-intensive frontend tasks to server-side plugins in systems like Trino and Elm, and even game ports like Doom. Projects such as Chicory (being forked into Endive under the Bytecode Alliance) highlight growing community involvement and governance shifts toward open, foundation-backed development. Performance has improved significantly through compilers that translate Wasm to efficient Java bytecode, leveraging JVM optimizations while minimizing dependencies - enabling fast, secure execution without native binaries. Despite limitations in concurrency, WebAssembly's role in enabling cross-language, portable, and safe computation continues to expand across cloud, embedded, and distributed systems.

• What if you shipped a secure, portable plugin system for your SaaS using WebAssembly today?

  • Move: Replace custom scripting (e.g., config-based logic or eval'd code) in your Java/Kotlin backend with WebAssembly modules compiled from Rust or JavaScript, using Endive (forked from Chicory) as the runtime.
  • Why Now?: Endive's upcoming release under the Bytecode Alliance ensures stronger security governance, and WASI P3 + component model support are stabilizing - making now the ideal time to lock in future-proof interfaces.
  • Expected Upside: Gain a sandboxed, cross-platform plugin architecture that lets users extend functionality safely without risking server stability - differentiating your product while reducing attack surface.

• What if you offloaded CPU-heavy tasks in your web app to WebAssembly on the JVM instead of relying on native binaries?

  • Move: Identify one performance-critical module (e.g., data parsing, encryption, image processing) and compile an existing C/Rust library (like Prism) to Wasm, then run it via Endive on your server-side JVM.
  • Why Now?: Recent 10x performance gains in Wasm-to-Java bytecode compilers (via Crane Lift Wasm JVM) make this viable for production use, especially with pure-Java runtimes eliminating JNI risks.
  • Expected Upside: Achieve near-native speed without OS-specific builds or native dependencies - simplifying deployment across environments while maintaining security and portability.

• What if you embedded customizable logic in your API tooling using lightweight WebAssembly UDFs like Trino does with CPython?

  • Move: Introduce user-defined functions (UDFs) in your data-processing service by allowing uploads of Wasm modules (from languages like Rust or Kotlin) that plug into your Java pipeline via Endive.
  • Why Now?: WASI's maturing interface specs and real-world validation in systems like Trino and Microx prove Wasm's viability for safe, composable logic injection - especially as Rhino/Nashorn deprecation pushes teams toward modern alternatives.
  • Expected Upside: Enable power users to inject business logic without forking your codebase, all within a secure, auditable sandbox - boosting retention and customization at low operational cost.

• Evaluate integrating WebAssembly (Wasm) into your Java-based projects to safely run untrusted or legacy code without JNI, leveraging its portability and sandboxing benefits.
• Adopt server-side WebAssembly for edge computing tasks using platforms like Cloudflare or Fastly, especially for lightweight, secure, and high-density workloads.
• Compile performance-critical libraries (e.g., C/C++ or Rust) to WebAssembly and run them on the JVM via tools like Chicory/Endive to avoid OS-specific binaries and improve security.
• Replace deprecated JavaScript engines (e.g., Nashorn, Rhino) in Java applications by embedding Quick.js via WebAssembly for scripting capabilities with minimal dependencies.
• Contribute to or adopt emerging WebAssembly runtimes like Endive (forked from Chicory) to stay aligned with community-driven, secure, and high-performance JVM-compatible Wasm execution.

• WebAssembly's core specification is complete, including Wasm GC and multi-memory, allowing languages like Scala, Kotlin, and Dart to run through compilers such as Scala.js.
• WASI P2 is nearly finalized, and WASI P3 is integrating with the component model to enable defining interfaces in WIDL files and composing applications from different Wasm components.
• Major CDN providers use WebAssembly at the edge for lightweight sandboxing, secure high-density workloads, and compute on durable objects.
• Server-side Wasm is active in production: Elm 4 uses Wasero for plugins, and Trino uses Chicory for CPython user-defined functions.
• The Prism Ruby parser was compiled to Wasm, enabling Ruby parsing on any JVM without native libraries, and a new compiler improved its performance by 10x.
• JavaScript integration in Java is shifting from deprecated engines like Rhino and Nashorn to WebAssembly-based runtimes like Quick.js, which Microx uses for embedded scripting.
• Rhino itself now uses WebAssembly as its underlying engine while preserving the same interface.
• A single-pass compiler translates WebAssembly bytecode directly to Java bytecode, allowing the JVM's JIT compilers to optimize execution and approach native performance over iterations.
• An experimental compiler leveraging Cranelift compiled to Wasm matches state-of-the-art Wasm runtimes without requiring native libraries.
• Chicory is written in pure Java, keeps external dependencies minimal, prioritizes security before performance, and often generates smaller code than the original Wasm.
• WebAssembly's memory model and single-threaded execution make it suitable for sandboxing untrusted code, but it lacks native concurrency and parallelism, requiring external orchestration for scaling.
• Rust-based core logic deployed as WebAssembly enables portability across Java, Go, Swift, and other languages, as seen with OpenFeature and Spotify Confidence.
• Multi-step translations like Java-to-Wasm-to-Java bytecode add inefficiency and are not recommended for production use.
• The Chicory project is being forked to Endive under the Bytecode Alliance, with original maintainers continuing development and governance moving to a foundation for broader community participation.