# chicory: A WebAssembly Runtime That Lives Inside the JVM

> Chicory is a WebAssembly runtime written in Java, which lets you run Wasm modules with no native dependencies and no JNI, so a jar stays a jar. Its design gives up raw speed on purpose: safety and a pure JVM footprint are stated goals, and being the fastest runtime is an explicit non-goal.

**dylibso/chicory** — Native JVM WebAssembly runtime

- Repository: https://github.com/dylibso/chicory
- Website: https://chicory.dev
- Stars: 1,145 · Forks: 77
- Language: Java
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/dylibso-chicory

## A Wasm Module That Runs Without Leaving the JVM

Chicory is a JVM native WebAssembly runtime, and the README's summary is precise about what that means: it runs WebAssembly programs with zero native dependencies or JNI, and can run Wasm anywhere the JVM can go. It is designed with simplicity and safety in mind, and it is a Java project rather than a C, C++ or Rust one.

The claim to check is the zero native dependency part. A Wasm runtime normally arrives as a platform binary, so the JVM process calling into it needs a foreign function interface. Chicory instead implements the Wasm execution model in Java, which means the module executes inside the same heap, under the same memory manager, with the same garbage collector, as the rest of your service.

The repository reflects that scope. Alongside runtime/ and compiler/ there are wasi/ for the WASI support, wasm/ for the module model, codegen/ for the code generation, cli/ for a command line entry point, jmh/ for the microbenchmarks, fuzz/ for fuzzing, machine-tests/, runtime-tests/, compiler-tests/ and android-tests/ for verification, and a wasm-corpus/ plus wasm-tools/ for test material. It is a large, serious codebase rather than a weekend experiment.

## Distribution Matrix and FFI: The Two Friction Points

The Why section is the most useful part of the README, because it names the two concrete problems a Java developer hits when embedding an existing Wasm runtime.

The first is distribution. The README lists the mature runtimes you could otherwise choose, including v8, wasmtime, wasmer, wasmedge and wazero, and points out that if you are distributing a Java library such as a jar or a war, you must now distribute alongside it a native object targeting the correct architecture and operating system. That matrix can become large, and it eliminates much of the simplicity and the original benefit of shipping Java code. The question to ask is not whether a native runtime is fast, but how many binaries your library now owes to every consumer.

The second is the runtime boundary. At runtime you have to use FFI to execute the module, and the README argues that while there may be performance benefits in some cases, doing this effectively escapes the safety and observability of the JVM. A pure JVM runtime means your security and memory guarantees, and your tools, stay in place.

So the trade Chicory is offering is not speed for nothing. It is a smaller distribution surface and a smaller trust boundary, in exchange for a runtime that executes Wasm the Java way.

## The Non-Goals Are the Most Useful Thing on the Page

Most project pages list goals. This one also lists what it refuses to be, and that list is short and blunt: Chicory is not a standalone runtime, it is not the fastest runtime, and it is not the right choice for every JVM project.

The stated goals sit next to them. Be as safe as possible, which the README qualifies by saying the project is willing to sacrifice things like performance for safety and simplicity. Make it easy to run Wasm in any JVM environment without native code, including very restrictive environments. Fully support the core Wasm spec. And make integration with Java, and other host languages, easy and idiomatic.

The restrictive environments point matters more than it first appears. A JVM application server with a restrictive security policy, a managed platform where loading a shared object is not allowed, or an environment where the deployment artefact must be a single file are all cases where a native runtime is not an option, and a pure Java implementation is the only way to run Wasm at all.

For an evaluator, the non-goals are the fastest way to decide whether to keep reading. If raw Wasm throughput is your primary requirement, the project has already told you where it stands.

## Two Engines: A Bytecode Interpreter and an Ahead-of-Time Compiler

The 2024 milestones include decoupling the interpreter and creating separate compiler and interpreter engines, and making all tests green with the interpreter, which the README marks as important for correctness. A proof of concept ahead-of-time compiler came next, followed by a stretch goal of an AOT engine that passes all the same specs as the interpreter. By 2025 the compiler had left experimental status.

That structure explains the badge row at the top of the README. There are three separate test result badges, for the interpreter, for the compiler and for WASI, which means the two engines are verified independently against the specification test suite rather than assuming that a module running on one behaves the same on the other.

The separation is also how the safety story is kept consistent. The interpreter executes Wasm directly in the JVM, which makes it the reference for correctness, while the compiler is an optimisation path that must reproduce the same observable behaviour. A project that publishes three independent conformance badge sets is telling you that the conformance is the product, not the speed.

The interpreter also received the feature work first. In the 2025 milestones, SIMD support is listed as being in the interpreter, and tail call in both the interpreter and the compiler, which is the practical detail to check if you are deciding which engine to use for a given module.

## The Roadmap Is Checked Off, Except for Performance

The roadmap runs from 2023 to 2026 and reads as an audit trail. In 2023 the project delivered the Wasm binary parser, a simple bytecode interpreter, the basic coding and testing patterns, and JUnit tests generated from the Wasm test suite. That last item is the foundation of the whole conformance story.

In 2024 came green tests across the interpreter, validation logic described as important for safety, a draft of the version 1.0 API for stability, the engine split, the AOT compiler, and WASIp1 support with its own test generation.

In 2025 the list is SIMD support, tail call, the compiler leaving experimental status, exception handling, threads support and extended constant expressions. In 2026 the entries are GC support and multi-memory support, and then a single unchecked box: performance.

The README is careful about the status of the roadmap, saying the milestones are subject to change and represent best guesses with current information, that they are not necessarily sequential, and that unless specified an unchecked box is still not planned or started. The one open item is therefore the one the non-goals section already flagged, and that consistency is a good sign for how the project communicates.

## WASI, Host Bindings and Where the Documentation Lives

WASI support arrived in 2024 and is tracked separately, with its own test generation and its own conformance badge. There is a dedicated wasi/ directory, a wasi-test-gen-plugin/ and a wasi-tests/ directory, and the documentation has a page on WASI usage linked from the roadmap.

The host integration is where a runtime either becomes usable in production or stays a curiosity, and the stated goal is to make integration with Java and other host languages easy and idiomatic. The repository layout supports that: the runtime/, compiler/, wasi/ and wasm/ modules are separate, and there is a cli/ for driving things from a command line, plus a build-time-compiler/ and a compiler-maven-plugin/ for ahead-of-time compilation inside a Maven build.

The project website at chicory.dev carries the getting started documentation, and there is a blog alongside it. The README also asks you to reach out and tell them what you are building with Chicory, and points to a Zulip chat with an invite link, which is where a developer evaluating a runtime with this many moving parts will get the most useful answers.

## Where Chicory Is the Wrong Choice

There are three situations where a pure Java Wasm runtime is the wrong answer, and the project is honest enough to name all three of them itself.

The first is throughput. The non-goals say it plainly, and the roadmap still has performance open. If your workload runs Wasm continuously and the wall clock is the constraint, a native runtime with an ahead-of-time compiled module is a different proposition, and Chicory is not competing for that job.

The second is the standalone case. Chicory is explicitly not a standalone runtime, so it is not a command line tool you point at a.wasm file outside a JVM, and it is not what you want if your deployment unit is a process rather than a jar.

The third is the general purpose case. The non-goals include not being the right choice for every JVM project, and the honest reading is that Chicory is aimed at the specific case of embedding untrusted or third-party Wasm inside a Java service, where the distribution and the trust boundary arguments in the Why section dominate.

What is left is a genuinely useful niche. A Java service that wants to run a plugin written in Wasm, or a Quarkus service that wants a sandbox for third-party code, gets a module that stays inside the JVM, ships as an ordinary jar, and inherits the memory safety and the tooling of the platform it already runs on. That niche is narrower than a general Wasm runtime, and it is the niche Chicory is built for.

## Conclusion

Chicory fits a Java or Quarkus service that needs to execute untrusted or third-party Wasm modules while keeping a single jar deployment, JVM level memory safety, and the observability and tooling that come from staying inside the JVM. It is a poor fit for a workload where Wasm execution speed is the primary requirement, because the project states plainly that being the fastest runtime is a non-goal and that the 2026 roadmap still has performance as an open item. Before adopting it, check which of the engine and WASI capabilities you actually need, because the roadmap distinguishes the interpreter from the compiler for several features, and note that the newest release is 1.7.5 from 2026-03-24 with the last push on 2026-07-06.

## FAQ

### What is Chicory and how is it different from other WebAssembly runtimes?

Chicory is a WebAssembly runtime written in Java that runs Wasm modules with zero native dependencies and no JNI. The README lists v8, wasmtime, wasmer, wasmedge and wazero as alternatives, and explains that embedding a native runtime means distributing a platform binary per architecture and calling it through FFI at runtime.

### Does Chicory support WASI?

Yes. WASIp1 support is listed among the 2024 roadmap milestones, with its own test generation, a wasi/ directory in the repository, a wasi-test-gen-plugin/ and a wasi-tests/ directory, and a separate WASI conformance badge in the README.

### Is Chicory the fastest WebAssembly runtime?

No, and the project says so. The non-goals list states that Chicory is not the fastest runtime and not a standalone runtime, and the 2026 roadmap has performance as the one unchecked item, with the goal being to sacrifice performance where needed for safety and simplicity.

### What WebAssembly features does Chicory support?

The roadmap records SIMD support, tail call, exception handling, threads support and extended constant expressions for 2025, with GC support and multi-memory support for 2026, and the goals state full support of the core Wasm spec. The interpreter and the compiler are separate engines with their own test results.

### How do I get started with Chicory?

The README points to the official documentation at chicory.dev/docs and to the getting started page there, and it invites questions on the project Zulip chat. The project also asks you to tell them what you are building with Chicory.

## Sources

- [dylibso/chicory on GitHub](https://github.com/dylibso/chicory)
- [License: Apache-2.0](https://github.com/dylibso/chicory/blob/main/LICENSE)
- [Project website](https://chicory.dev)
- [README](https://github.com/dylibso/chicory/blob/main/README.md)
- [Releases](https://github.com/dylibso/chicory/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dylibso-chicory