▲ 201 points
back
95 comments
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...
I don't understand logic and layers of abstraction here.
Chicory runs on JVM. Bazel runs on JVM. How inserting WebAssembly layer will help to eliminate platform-specific helper binaries? These binaries compiled to WebAssembly will be run, effectively, on JVM (through one additional layer of APIs provided by Chicory), right? Why you cannot write these helpers directly in JVM language, Java, Kotlin, Clojure, anything? Why do you need additional layer of Chicory?
You don't, just, easily rewrite everything.
Being able to just re-use is the trick!
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.
Looking forward to seeing more Chicory in Bazel, is a great use-case! Thanks for spearheading it!
> 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 thought Java had all of this sandboxing stuff baked in? Wasn't that a big selling point for the JVM once upon a time? Every other WASM thread has someone talking about how WASM is unnecessary because JVM exists, so the idea that JVM actually needs WASM to do sandboxing seems pretty surprising!
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
Some more interesting use cases in production:
Running python UDFs in Trino: https://trino.io/docs/current/udf/python.html
Running the Ruby parser in Jruby: https://blog.enebo.com/2024/02/23/jruby-prism-parser.html
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.
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
How does it compare to graal wasm? https://github.com/oracle/graal/blob/master/wasm/README.md/
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
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.
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
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!
Related. Others?
Chicory 1.0.0-M1: First Milestone Release - https://news.ycombinator.com/item?id=42086590 - Nov 2024 (3 comments)
A Zero-Dependency WebAssembly Runtime for the JVM - https://news.ycombinator.com/item?id=38759030 - Dec 2023 (1 comment)
I'd like to take a moment to appreciate how cute the name is.
Love stuff like that.
Glad you appreciate it! On top of being a Java joke it’s an homage to my home, New Orleans. We still drink coffee with chicory here due to some events during the civil war and then a changed cultural taste. Though the history in this isn’t exactly clear I think https://neworleanshistorical.org/items/show/1393
Came here to say the same thing, excellent name.
For people who aren't aware, Chicory has long been used (e.g. in Europe during WW2) as a coffee substitute, and Java is another name for coffee, thus Chicory is a substitute for Java.
Edit: I originally thought Chicory was a JVM replacement using WebAssembly (e.g. to run Java applets in modern browsers, using WebAssembly). It appears that it's actually a WebAssembly runtime, to run WebAssembly code on the JVM. So the name is a lot less cool than I thought it was.
it really is a perfect name. credit to u/bhelx!
For some reason, I think that instead a Java runtime written in WebAssembly would be more useful.
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
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.
TeaVM https://www.teavm.org/
Then you'll be run Java in the browser! Wait, isn't that applets?
Java runtime without miltithreading? No thanks.
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.
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
thinking about that makes we want to see a performance comparison of WASM code running in Chicory vs running on other non-Java WASM hosts
Chicory is how we're able to run newly popular MCP servers on Android!
https://docs.mcp.run/blog/2024/12/27/running-tools-on-androi...
How far is this from the hypothetical (I think, for now) scenario of including a WASM build as a fallback "platform" in jars that include some native code for a number of platforms? A number of platforms that will never be complete, not when you include the future?
I would say pretty close, check this for example: https://github.com/roastedroot/sqlite4j
Is it only me who is interested in creating minecraft plugins in go code which can compile to wasm and now run in chicory natively in the jvm itself , sure there is some overhead but oh I don't mind that , I think that somebody would want to hook the minecraft api to be callable from wasm and then some more shenanigans on the wasm side as well and then on the golang side as well but oh boy , It can be fun. I really wanted to create a python minecraft plugin when I was really young / just starting out programming , I really was close to learning kotlin just for minecraft.
Minecraft holds dear to me.
I'm not sure where they congregate, but I've encountered some minecraft people using chicory probably for this purpose. IDK how minecrafts plugins currently work but i'd imagine chicory is more secure and the overhead may be worth it for some cases.
I'd think an RPC would be the cleaner pattern, but I don't know how to deploy a service-oriented Minecraft server.
I want to do the opposite I want to run jvm languages on wasm
There are a few efforts in this direction, TeaVM but also Graal, I think you just need to stay tuned
Would Scala be able to run on this?
Yes i think so. it's just a jar
Can we use any JVM language, like Clojure?
I think it's the other direction isn't it? As in, it's a runtime written in Java that runs WebAssembly, not a JVM that runs on WebAssembly.
I could be wrong but that's the impression I got.
Yes, you should be able to call wasm stuffs from Clojure with it too.
This is distributed as just a jar, should you can invoke it from Clojure, if that is what you mean.
I feel like a WASM-native JVM runtime would make more sense these days
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.
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.