Chicory Redline
Build time Compiler for Wasm in Java.
⚠️ Experimental — This project is under active development. APIs may change without notice.
Chicory Redline is a near drop-in replacement for Chicory's build-time compiler. Instead of compiling Wasm to JVM bytecode, it uses Cranelift(the same engine used by Wasmtime) to generate native machine code at build time, then executes it at runtime through a foreign function interface.
The compilation pipeline:
- Build time -- The Maven plugin feeds your
.wasmfile to Cranelift (itself compiled to Wasm and executed via Chicory) which produces native machine code for each supported platform. The generated code is bundled as resources in your JAR. - Runtime -- Native code is loaded and executed via one of two backends, selected automatically through SPI:
- Panama FFM (Java 25+, zero extra dependencies, preferred when available)
- jffi (Java 11+, adds ~200KB)
- Fallback -- When the target architecture/OS has no precompiled native code, Redline can fall back to Chicory's pure-Java bytecode compiler transparently.
Other projects integrate Wasmtime (or similar runtimes) via JNI bindings to a platform-specific native library. Redline takes a different path: Cranelift itself is compiled to Wasm and executed at build time through Chicory. There is no native compiler to ship, link, or maintain -- and on Java 25+ (Panama) the result is zero runtime dependencies.
| OS | x86_64 | aarch64 |
|---|---|---|
| Linux | yes | yes |
| macOS | yes | yes |
| Windows | yes | yes |
On any other platform the bytecode fallback (when enabled) takes over automatically.
Chicory Redline combines the security guarantees of WebAssembly with the raw speed of native machine code, powered by Cranelift, the same production-grade compiler backend trusted by Wasmtime.
- Bounds-checked memory access -- Cranelift generates bounds-checked assembly for every linear memory access, enforcing WebAssembly's sandboxing model at native speed.
- Java-managed off-heap memory -- All off-heap memory (linear memory, globals, code regions) is allocated through Java-managed structures (Panama
Arena/ jffiMemoryIO), ensuring proper lifecycle management. - Read-execute only code pages -- Compiled code pages are mapped read-execute only and cannot be modified after compilation.
The result is maximum throughput with the safety properties of WebAssembly's separate heap memory model, performance that we have proven, JVM bytecode alone cannot match.
Works on Java 11+. Uses native code when available, falls back to Chicory bytecode otherwise.
Dependency:
<dependency>
<groupId>io.roastedroot</groupId>
<artifactId>redline</artifactId>
<version>${redline.version}</version>
</dependency>Maven plugin:
<plugin>
<groupId>io.roastedroot</groupId>
<artifactId>redline-compiler-maven-plugin</artifactId>
<version>${redline.version}</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<name>com.example.MyModule</name>
<wasmFile>src/main/resources/my-module.wasm</wasmFile>
</configuration>
</execution>
</executions>
</plugin>The Maven plugin generates a class (specified by <name>) with a builder() method. If you're familiar with Chicory's Instance, the usage is very similar:
// The generated class provides a builder that auto-selects the best backend
try (var instance = MyModule.builder().build()) {
var result = instance.instance().export("my_function").apply();
System.out.println(result[0]);
}Always use try-with-resources -- instances hold off-heap native code and memory that must be released.
You can check which backend is active at runtime:
try (var instance = MyModule.builder().build()) {
if (instance.isNative()) {
System.out.println("Running native (Cranelift)");
} else {
System.out.println("Running bytecode (Chicory)");
}
}Prerequisites: Java 25 and Maven 3.9+ for a full build (Java 11 is enough for the compiler and jffi backend only).
mvn clean install -P panama,panama-tests,jffi,ciSee CONTRIBUTING.md for the full build guide, architecture overview, and code style guidelines.
Chicory Redline builds on the shoulders of two great projects: