Chicory: A JVM native WebAssembly runtime
34 comments
·February 25, 2025andreaTP
bhelx
[delayed]
ncruces
Looking forward to this reviving NestedVM's pure Java SQLite. It's only been (checks notes…) 20 years.
https://benad.me/blog/2008/1/22/nestedvm-compile-almost-anyt...
To be clear: I'm fully supportive of this effort. NestedVM's SQLite is 100% my inspiration for my Wasm based Go SQLite driver.
evacchi
also the chicory Extism SDK https://github.com/extism/chicory-sdk and the mcpx4j library used for mcp.run Java integration, see e.g. https://docs.mcp.run/tutorials/mcpx-spring-ai-java
...and Chicory works on Android too https://docs.mcp.run/tutorials/mcpx-gemini-android
jmillikin
Chicory seems like it'll be pretty useful. Java doesn't have easy access to the platform-specific security mechanisms (seccomp, etc) that are used by native tools to sandbox their plugins, so it's nice to have WebAssembly's well-designed security model in a pure-JVM library.
I've used it to experiment with using WebAssembly to extend the Bazel build system (which is written in Java). Currently there are several Bazel rulesets that need platform-specific helper binaries for things like parsing lock files or Cargo configs, and that's exactly the kind of logic that could happily move into a WebAssembly blob.
https://github.com/jmillikin/upstream__bazel/commits/repo-ru...
andreaTP
Looking forward to seeing more Chicory in Bazel, is a great use-case! Thanks for spearheading it!
gf000
I really don't want to sound flamewar-y, but how is WebAssmebly's security model well-designed compared to a pure Java implementation of a brainfuck interpreter? Similarly, java byte code is 100% safe if you just don't plug in filesystem/OS capabilities.
It's trivial to be secure when you are completely sealed off from everything. The "art of the deal" is making it safe while having many capabilities. If you add WASI to the picture it doesn't look all that safe, but I might just not be too knowledgeable about it.
kannanvijayan
It's really difficult to compare the JVM and wasm because they are such different beasts with such different use cases.
What wasm brings to the table is that the core tech focuses on one problem: abstract sandboxed computation. The main advantage it brings is that it _doesn't_ carry all the baggage of a full fledged runtime environment with lots of implicit plumbing that touches the system.
This makes it flexible and applicable to situations where java never could be - incorporating pluggable bits of logic into high-frequency glue code.
Wasm + some DB API is a pure stored procedure compute abstraction that's client-specifiable and safe.
Wasm + a simple file API that assumes a single underlying file + a stream API that assumes a single outgoing stream, that's a beautiful piece of plumbing for an S3 like service that lets you dynamically process files on the server before downloading the post-processed data.
There are a ton of use cases where "X + pluggable sandboxed compute" is power-multiplier for the underlying X.
I don't think the future of wasm is going to be in the use case where we plumb a very classical system API onto it (although that use case will exist). The real applicability and reach of wasm is the fact that entire software architectures can be built around the notion of mobile code where the signature (i.e. external API that it requires to run) of the mobile code can be allowed to vary on a use-case basis.
hinkley
The bespoke capability model in Java has always been so fiddly it has made me question the concept of capability models. There’s was for a long time a constant stream of new privilege escalations mostly caused by new functions being added that didn’t necessarily break the model themselves, but they returned objects that contained references to objects that contained references to data that the code shouldn’t have been able to see. Nobody to my recollection ever made an obvious back door but nonobvious ones were fairly common.
I don’t know where things are today because I don’t use Java anymore, but if you want to give some code access to a single file then you’re in good hands. If you want to keep them from exfiltrating data you might find yourself in an Eternal Vigilance situation, in which case you’ll have to keep on top of security fixes.
We did a whole RBAC system as a thin layer on top of JAAS. Once I figured out a better way to organize the config it wasn’t half bad. I still got too many questions about it, which is usually a sign of ergonomic problems that people aren’t knowledgeable enough to call you out on. But it was a shorter conversation with fewer frowns than the PoC my coworker left for me to productize.
bhelx
WASI does open up some holes you should be considerate of. But it's still much safer than other implementations. We don't allow you direct access to the FS we use jimfs: https://github.com/google/jimfs
I typically recommend people don't allow wasm plugins to talk to the filesystem though, unless they really need to read some things from disk like a python interpreter. You don't usually need to.
pjmlp
Pssst, it is the usual WebAssembly sales pitch.
Linear memory accesses aren't bound checked inside the linear memory segment, thus data can still be corrupted, even if it doesn't leave the sandbox.
Also just like many other bytecode based implementations, it is as safe as the implementations, that can be equally attacked.
https://webassembly.org/docs/security/
https://www.usenix.org/conference/usenixsecurity20/presentat...
https://www.usenix.org/conference/usenixsecurity21/presentat...
https://www.usenix.org/conference/usenixsecurity22/presentat...
vips7L
How does it compare to graal wasm? https://github.com/oracle/graal/blob/master/wasm/README.md/
evacchi
take a look at this blog post, these are early results but we collaborated with the Graal team for a fair comparison https://chicory.dev/blog/chicory-1.0.0#the-race-day
bhelx
Also note, we have the AOT compiler which can target the JVM bytecode directly as well as Dalvik/Android which is experimental but nearly spec complete :)
null
remexre
It'd be interesting to see a benchmark for what the total overhead is for Rust->WASM->Chicory AoT->native-image versus native Rust; I've been pleasantly surprised by the JVM in the past, so I'd hope it'd be a relatively small hit.
bhelx
Even in interpreter mode, rust wasm programs seem very fast for me on Chicory. I'm not sure if we have any specific benchmarks but the graal team did some and i think it's based on a rust guest program https://chicory.dev/blog/chicory-1.0.0/#the-race-day
andreaTP
ahaha, that's intriguing! I think there are still some gaps but we are comparing results(with GraalWasm) on Photon here: https://github.com/shaunsmith/wasm-bench Should be easy to build a native image and compare!
DrNosferatu
For some reason, I think that instead a Java runtime written in WebAssembly would be more useful.
bhelx
There are a few, and they are really interesting! The reason we wrote Chicory though is we're interested in extending the capabilities of existing Java applications through plugins. The intro of this talk explains some of this reasoning: https://www.youtube.com/watch?v=00LYdZS0YlI
giancarlostoro
Not sure why you're being downvoted. One of the best tools Microsoft made regarding WebAssembly and C# is Blazor. Developers can focus on building web applications and use C# on both the front-end and back-end and drive the UI either server side or WASM without missing a beat. Essentially bypassing the need for JavaScript.
I can only imagine such a capability for Java or other languages would be infinitely useful.
slt2021
Google web toolkit was released 18 yers ago that essentially allowed you to create early web2.0 apps (like Gmail) in Java. AJAX and a lot of web2.0 innovations were essentially originated from GWT
cogman10
Arguably, GWT was too ambitious. That made it somewhat of a PITA to work with.
J2CL is a much better approach (IMO) but is somewhat too little too late.
The best analogy to what GWT was is ASP.NET Webforms but ran on the client. That extra baggage (along with an antiquated build system and setup) made it really hard to keep GWT up to date.
I'm excited to see Java bytecode->WASM though. Now that WASM ships with a GC we should see some really neat stuff in terms of the size of the runtime needed for an AOT bytecode->wasm.
gf000
I would even argue that large scale JS web apps were plain impossible without Google Closure (the compiler they used to compile both Java and JS to JS, and to add types to JS) at the time.
ertucetin
Can we use any JVM language, like Clojure?
gdsdfe
I want to do the opposite I want to run jvm languages on wasm
dpratt
This looks very cool - I'm going to read into the implementation, there's something about producing JVM bytecode from WASM instructions and then having the JVM JIT compile it into native instructions that amuses me.
bhelx
It's very amusing to me as well. The first thing i did was run and SNES emulator and definitely made me chuckle https://x.com/bhelx/status/1809235314839281900
fabiofzero
I feel like a WASM-native JVM runtime would make more sense these days
dapperdrake
There is TeaVM for whatever it’s worth.
JavaScript and WASM really seem more portable. They have now approximated what Java web applets tried to achieve. And now WASM can be run in Mainframe IBM JVMs. Nashorn or Rhino seems like it runs JavaScript there.
JavaScript and WASM are now getting close to COBOL's importance. That’s no mean feat.
bhelx
There are a few! But also there is lots of Java software out there and Wasm is a great way to extend it and bring new functionality.
A few cool things based on Chicory:
OPA: https://github.com/StyraInc/opa-java-wasm
Integration with Debezium has been launched today too: https://debezium.io/blog/2025/02/24/go-smt/
And SQLite will come next: https://github.com/roastedroot/sqlite4j