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...
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
How does it compare to graal wasm? https://github.com/oracle/graal/blob/master/wasm/README.md/
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.
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.
For some reason, I think that instead a Java runtime written in WebAssembly would be more useful.
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.
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?
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 want to do the opposite I want to run jvm languages on wasm
Would Scala be able to run on this?
Can we use any JVM language, like Clojure?
[dead]
I feel like a WASM-native JVM runtime would make more sense these days