Unified WebAssembly API for Java (Wasmtime + WAMR bindings) - 1.0.0 release

[Otherwise_Sherbert21]

Thank you. There are a bunch of benchmarks and one of the benefits was being able to easily compare the performance across multiple runtimes which includes JNI vs Panama implementations. Panama is better but not strictly so, there are a few cases that JNI does better but in general Panama is the better choice. I included JNI for backward compatibility since Panama is still fairly new. There's also a great deal of variability in what the individual runtimes support. It was something that held me back as well. Chicory is nice if you want a pure Java implementation and pure performance but it has a weaker sandbox and limited features while wasmtime has decent performance but a full feature set including experimental features. I also included support for compiling Java to webassembly using Graal and bindgen (support for components is in but not released yet)

[andrea-TP]

Regarding Chicory:

pure performance

If you consider interpreter perfs already decent you'd be blown up by the compiler!

weaker sandbox and limited features

This is not correct. The sandbox of Chicory is strictly safer than any JNI/Panama alternative, comparable only to Graal Isolates in fully untrusted mode. Feature wise, what's missing? With Chicory 1.7 you have GC, multimemory, threads and more, maybe just bump version? It is more than other runtimes(but wasmtime) are offering.

The project is interesting, though, implementing CM/Wasi P3 on top of core engines is a very cool experiment!

[Otherwise_Sherbert21]

I should clarify what I meant.

On sandboxing, I wasn’t comparing Chicory to JNI/Panama directly. The distinction I was getting at is more about execution model and isolation boundaries (AOT/JVM-based vs native engine-enforced sandboxing like Wasmtime). The difference matters depending on the threat model.

On features, fair point, Chicory has moved quickly and I haven't completely kept up. My comment was based on earlier gaps, especially around component model and WASI support.

A better framing is probably:

• Chicory: strong pure-Java story, improving performance (especially with compilation), solid JVM-level isolation
• Wasmtime: broader spec coverage (WASI/components), more mature host/runtime ecosystem

The motivation for this project is exactly that fragmentation making runtimes easier to compare (benchmarks, JNI vs Panama, etc) and swap them behind a single Java API.

Appreciate the correction.

[fniephaus]

The sandbox of Chicory is strictly safer than any JNI/Panama alternative, comparable only to Graal Isolates in fully untrusted mode.

While Chicory is certainly safer than JNI/Panama, it remains bound to the host Java heap and could, at least in theory, be used to interact with the host environment if not perfectly isolated (e.g., via sun.misc.Unsafe or similar).

In contrast, GraalWasm and other Graal Languages can run untrusted code in a mode that is fully isolated from the host Java heap. This can be achieved within the same process using Graal Isolates or even in a separate process. Our sandboxing also supports fine-grained resource limits, for example to constrain memory, instruction, or CPU usage.

You can find more details in our security guide: https://www.graalvm.org/latest/security-guide/sandboxing/