Introduction: the promise of “embed once, run anywhere” reimagined
What if you could embed native‑level capabilities into your Java applications, think of database engines, scripting runtimes, policy interpreters, even compilers and still remain pure Java, with no JNI, no native binaries, no concerns about OS or architecture compatibility? That is the promise of combining WebAssembly (Wasm) with the zero dependencies runtime Chicory.
The year 2025 feels like a turning point for this model. Chicory is no longer just an advanced exercise or a runtime prototype. It is powering a growing ecosystem of real‑world Java libraries. “Embed once, run anywhere” is no longer a slogan, it is becoming practical. In this post, we will explore why Chicory matters, what has been built upon it so far, and why you (as a Java developer or architect) should care today.
What is Chicory and why it matters
Chicory is a JVM‑native WebAssembly runtime. It allows you to run Wasm modules with zero native dependencies or JNI. As long as the JVM runs, the Wasm‑derived code runs.
Most existing Wasm runtimes (for example V8, Wasmtime, Wasmer, Wasmedge) are often written in C/C++/Rust. Embedding them in a Java application requires shipping native binaries for every supported platform, complicating distribution and deployment.
By contrast, Chicory eliminates that burden. You just depend on a JAR. This design brings structural advantages:
- Portability: if the JVM can run, the same Wasm module can run everywhere. No need to build per OS or architecture.
- Sandboxing and JVM integration: the Wasm module executes inside the JVM sandbox, on a managed isolated heap, preserving JVM memory safety, garbage collection, observability, tooling.
- Simplicity: no external native dependencies, no packaging matrix across OS/architecture, no JNI trouble.
Chicory re-imagines the classic “write once, run anywhere” Java promise. It extends it beyond Java bytecode, enabling WebAssembly modules that let you embed seamlessly powerful native features, while staying inside the JVM.
Chicory execution modes: flexibility for development and production
One of the strengths of Chicory is that it supports multiple ways of executing Wasm modules, letting you choose the trade‑off between portability and performance.
Here is an overview:
| Mode | Description | When to Use |
| Interpreter | Default mode. Executes Wasm modules directly, without compilation. It requires no extra dependencies and is maximally portable. | During development, dynamic loading, or when you want maximum flexibility. |
| Runtime Compilation | On-the-fly compilation of Wasm modules into Java bytecode (in‑memory) and dynamic loading. This requires an additional dependency (ASM) but improves execution performance significantly. | Useful when you need better performance while still allowing dynamic module loading. |
| Build‑time Compilation | Compile Wasm modules into plain Java bytecode at build time (via Maven/Gradle plugin). You get standard class/JAR artifacts and avoid runtime compilation overhead altogether. | For production deployments with static modules and where performance is important. |
With the release of Chicory 1.4.0, the compiler (both runtime and build‑time) and the annotations system became stable.
More recently, Chicory 1.6.0 added support for the Java Platform Module System (JPMS), a directory‑backed runtime‑compiler cache (improving startup for repeated module loads), enhanced support for the Wasm “Threads” proposal(atomic fence instructions and atomic ops), increased Wasm spec conformance and verified compatibility with Java 25.
Thanks to this flexibility, libraries and applications can choose the mode that fits their use case: from dynamic scripting in dev to high‑performance embedded Wasm in production.
Real‑world “native‑free” tools built on Chicory
One of the strongest signals that the Wasm‑on‑JVM model is maturing is the growing number and quality of real libraries now using Chicory.
Here are some of the most notable:
QuickJs4j: a sandboxed JavaScript runtime for Java. QuickJS (originally a C engine) is compiled to WebAssembly, then Chicory compiles that Wasm into pure Java bytecode. The result is a small, self‑contained JAR runtime.
QuickJs4J’s is already powering the Microcks JavaScript dispatcher and Apicurio’s Registry custom artifact types.
SQLite4j: a pure‑Java SQLite JDBC driver. SQLite (originally written in C) is compiled to WebAssembly, then translated via Chicory to JVM bytecode. This allows embedding the full power of the most used lightweight SQL database inside Java without the need to ship native binaries.
Opa‑java‑wasm: is the WebAssembly-powered version of the policy engine Open Policy Agent (OPA), delivered for Java via Chicory. It powers in-process OPA policy evaluation removing the network calls required by more traditional integrations and, again, no native dependencies.
Beyond these, the “Who uses Chicory?” list includes many other use cases: user-defined functions for data engines, plugin systems, scripting inside data frameworks and more.
These are not toy examples. They deliver widely relevant capabilities: a JavaScript runtime, an embedded database and a policy engine. They show that Wasm + JVM is not just a thought experiment; it is already powering production‑ready tools.
Why this matters for Java developers and enterprises
For years, Java developers have accepted a painful tradeoff: whenever you needed to interact with libraries originally written in system programming languages, you ended up either rewriting the full thing or using JNI, FFI, native binaries, and OS/architecture‑specific builds. Packaging, deployment complexity, native-library hell became a recurring burden.
Chicory changes that math. With Wasm + Chicory + appropriate libraries, you can embed powerful functionality without leaving the JVM or shipping native dependencies.
New architectural patterns are emerging: plugin systems, embedded scripting engines, user-provided logic, sandboxed extensions, policy engines can now run within a JVM and with a controlled ABI surface.
For enterprise and cloud‑native applications, this significantly reduces operational complexity, simplifies deployment across environments and improves maintainability enabling wider code re-use.
Where things stand: momentum, community and next steps
The ecosystem around Chicory is gaining tangible momentum. With stable compiler support, modularity, improved performance, cache support, and a lot of emerging libraries and integrations, the year 2025 feels like the moment when this technology shifted from “experimental runtime” to a useful building block.
Now is a great time to try things out!
Try embedding a Wasm‑compiled module into your Java project using Chicory and help us shape the future of native‑free, polyglot tooling for the JVM.
Conclusion: reimagining “write once, run anywhere” for modern needs
Chicory re-imagines Java’s classic “write once, run anywhere” promise:extending it beyond Java bytecode to WebAssembly modules compiled into JVM bytecode. With Chicory, you can embed powerful, native‑level capabilities inside Java applications, while retaining the safety, portability and simplicity of pure Java.
If you are a Java developer or architect still wrestling with native dependencies or painfully shipping platform‑specific binaries perhaps it is time to look again. Chicory and the growing ecosystem of libraries around it shows that you can have your cake and eat it too.
Give it a try now. The future of native‑free, polyglot-powered Java tooling may depend on it.
Author: Andrea Peruffo
With nearly two decades of coding experience, I’m fueled by passion as I continue to type away daily.
As a Principal Software Engineer at IBM, I actively contribute to diverse Open Source projects, driven by both personal fulfillment and professional advancement. My not-so-secret passion lies in programming languages, developer tools, compilers, and beyond. Come and spot me on a project near you!
steinhauer.software