6 ms·

Chicory: A JVM native WebAssembly runtime

201 points by 0x54MUR41 2y ago

remexre 2y ago
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 2y ago
  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 https://chicory.dev/blog/chicory-1.0.0/#the-race-day
- andreaTP 2y ago
  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 https://github.com/shaunsmith/wasm-bench Should be easy to build a native image and compare!
dpratt 2y ago
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 2y ago
  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 https://x.com/bhelx/status/1809235314839281900
- anentropic 2y ago
  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
vips7L 2y ago
How does it compare to graal wasm? https://github.com/oracle/graal/blob/master/wasm/README.md/ https://github.com/oracle/graal/blob/master/wasm/README.md/
- evacchi 2y ago
  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 https://chicory.dev/blog/chicory-1.0.0#the-race-day
  - bhelx 2y ago
    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 :)
  - titzer 2y ago
    Wizard's slow interpreter also runs on the JVM, albeit it very, very slowly. Have you done any benchmarking against Wizard?
    - evacchi 2y ago
      we should!
- deleted 2y ago
  [deleted]
jmillikin 2y ago
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-rule-execute-wasm/ https://github.com/jmillikin/upstream__bazel/commits/repo-ru... https://github.com/bazelbuild/bazel/discussions/23487 https://github.com/bazelbuild/bazel/discussions/23487
- gf000 2y ago
  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.
  - bhelx 2y ago
    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 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 2y ago
    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://webassembly.org/docs/security/ https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... https://www.usenix.org/conference/usenixsecurity21/presentation/narayan https://www.usenix.org/conference/usenixsecurity21/presentat... https://www.usenix.org/conference/usenixsecurity22/presentation/bosamiya https://www.usenix.org/conference/usenixsecurity22/presentat...
fabiofzero 2y ago
I feel like a WASM-native JVM runtime would make more sense these days
- dapperdrake 2y ago
  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.
  - evacchi 2y ago
    fun fact: there is an ongoing effort to bring Wasm to Rhino via Chicory https://github.com/mozilla/rhino/discussions/1485 https://github.com/mozilla/rhino/discussions/1485
- bhelx 2y ago
  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.
DrNosferatu 2y ago
For some reason, I think that instead a Java runtime written in WebAssembly would be more useful.
- giancarlostoro 2y ago
  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 2y ago
    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 https://en.wikipedia.org/wiki/Google_Web_Toolkit https://en.wikipedia.org/wiki/Google_Web_Toolkit
    - gf000 2y ago
      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.
    - cogman10 2y ago
      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.
- titzer 2y ago
gdsdfe 2y ago
I want to do the opposite I want to run jvm languages on wasm
- andreaTP 2y ago
  There are a few efforts in this direction, TeaVM but also Graal, I think you just need to stay tuned
  - evacchi 2y ago
    also https://github.com/mirkosertic/Bytecoder https://github.com/mirkosertic/Bytecoder and https://github.com/i-net-software/JWebAssembly https://github.com/i-net-software/JWebAssembly as well as the already mentioned (in some other comment) https://cheerpj.com/ https://cheerpj.com/ most of them are still experimental, while CheerpJ offers Enterprise support (but it targets the browser). oh, and let's not forget j2cl https://github.com/google/j2cl https://github.com/google/j2cl
andreaTP 2y ago
A few cool things based on Chicory: OPA: https://github.com/StyraInc/opa-java-wasm https://github.com/StyraInc/opa-java-wasm Integration with Debezium has been launched today too: https://debezium.io/blog/2025/02/24/go-smt/ https://debezium.io/blog/2025/02/24/go-smt/ And SQLite will come next: https://github.com/roastedroot/sqlite4j https://github.com/roastedroot/sqlite4j
- ncruces 2y ago
  Looking forward to this reviving NestedVM's pure Java SQLite. It's only been (checks notes…) 20 years. http://nestedvm.ibex.org/ http://nestedvm.ibex.org/ https://benad.me/blog/2008/1/22/nestedvm-compile-almost-anything-to-java 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 2y ago
  also the chicory Extism SDK https://github.com/extism/chicory-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 https://docs.mcp.run/tutorials/mcpx-spring-ai-java ...and Chicory works on Android too https://docs.mcp.run/tutorials/mcpx-gemini-android https://docs.mcp.run/tutorials/mcpx-gemini-android
- bhelx 2y ago
  Some more interesting use cases in production: Running python UDFs in Trino: https://trino.io/docs/current/udf/python.html 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 https://blog.enebo.com/2024/02/23/jruby-prism-parser.html
ertucetin 2y ago
Can we use any JVM language, like Clojure?
- tombert 2y ago
  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.
  - evacchi 2y ago
    that is correct
- bhelx 2y ago
  This is distributed as just a jar, should you can invoke it from Clojure, if that is what you mean.
- fulafel 2y ago
  Yes, you should be able to call wasm stuffs from Clojure with it too.
nilslice 2y ago
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-android/ https://docs.mcp.run/blog/2024/12/27/running-tools-on-androi...
asimpletune 2y ago
Would Scala be able to run on this?
- bhelx 2y ago
  Yes i think so. it's just a jar
  - andreaTP 2y ago
    Scala needs the Garbage Collection and Exception Handling proposals(afaik). They are planned but not implemented yet in Chicory.
    - bhelx 2y ago
      wait, was the question running scala in wasm or running chicory in scala?
      - andreaTP 2y ago
        To wasm or not to wasm. Well, running Chicory in Scala is seamless, I thought this comment was targeting the effort to compile Scala to Wasm in the Scala.js project.
dang 2y ago
Related. Others? Chicory 1.0.0-M1: First Milestone Release - https://news.ycombinator.com/item?id=42086590 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 https://news.ycombinator.com/item?id=38759030 - Dec 2023 (1 comment)
skyyler 2y ago
I'd like to take a moment to appreciate how cute the name is. Love stuff like that.
- nilslice 2y ago
  it really is a perfect name. credit to u/bhelx!
- gregschlom 2y ago
  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.
- bhelx 2y ago
  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 https://neworleanshistorical.org/items/show/1393
usrusr 2y ago
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?
- andreaTP 2y ago
  I would say pretty close, check this for example: https://github.com/roastedroot/sqlite4j https://github.com/roastedroot/sqlite4j
Imustaskforhelp 2y ago
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.
- bhelx 2y ago
  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.
- gavmor 2y ago
  I'd think an RPC would be the cleaner pattern, but I don't know how to deploy a service-oriented Minecraft server.
ursulasorensen 2y ago
[dead]

201 points by 0x54MUR41 2y ago

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 2y ago
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 https://chicory.dev/blog/chicory-1.0.0/#the-race-day
andreaTP 2y ago
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 https://github.com/shaunsmith/wasm-bench Should be easy to build a native image and compare!

dpratt 2y ago

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 2y ago
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 https://x.com/bhelx/status/1809235314839281900
anentropic 2y ago
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

vips7L 2y ago

How does it compare to graal wasm? https://github.com/oracle/graal/blob/master/wasm/README.md/ https://github.com/oracle/graal/blob/master/wasm/README.md/

evacchi 2y ago
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 https://chicory.dev/blog/chicory-1.0.0#the-race-day
- bhelx 2y ago
  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 :)
- titzer 2y ago
  Wizard's slow interpreter also runs on the JVM, albeit it very, very slowly. Have you done any benchmarking against Wizard?
  - evacchi 2y ago
    we should!
deleted 2y ago
[deleted]

jmillikin 2y ago

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-rule-execute-wasm/ https://github.com/jmillikin/upstream__bazel/commits/repo-ru... https://github.com/bazelbuild/bazel/discussions/23487 https://github.com/bazelbuild/bazel/discussions/23487

gf000 2y ago
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.
- bhelx 2y ago
  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 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 2y ago
  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://webassembly.org/docs/security/ https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... https://www.usenix.org/conference/usenixsecurity21/presentation/narayan https://www.usenix.org/conference/usenixsecurity21/presentat... https://www.usenix.org/conference/usenixsecurity22/presentation/bosamiya https://www.usenix.org/conference/usenixsecurity22/presentat...

fabiofzero 2y ago

I feel like a WASM-native JVM runtime would make more sense these days

dapperdrake 2y ago
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.
- evacchi 2y ago
  fun fact: there is an ongoing effort to bring Wasm to Rhino via Chicory https://github.com/mozilla/rhino/discussions/1485 https://github.com/mozilla/rhino/discussions/1485
bhelx 2y ago
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.

DrNosferatu 2y ago

For some reason, I think that instead a Java runtime written in WebAssembly would be more useful.

giancarlostoro 2y ago
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 2y ago
  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 https://en.wikipedia.org/wiki/Google_Web_Toolkit https://en.wikipedia.org/wiki/Google_Web_Toolkit
  - gf000 2y ago
    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.
  - cogman10 2y ago
    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.
titzer 2y ago

gdsdfe 2y ago

I want to do the opposite I want to run jvm languages on wasm

andreaTP 2y ago
There are a few efforts in this direction, TeaVM but also Graal, I think you just need to stay tuned
- evacchi 2y ago
  also https://github.com/mirkosertic/Bytecoder https://github.com/mirkosertic/Bytecoder and https://github.com/i-net-software/JWebAssembly https://github.com/i-net-software/JWebAssembly as well as the already mentioned (in some other comment) https://cheerpj.com/ https://cheerpj.com/ most of them are still experimental, while CheerpJ offers Enterprise support (but it targets the browser). oh, and let's not forget j2cl https://github.com/google/j2cl https://github.com/google/j2cl

andreaTP 2y ago

A few cool things based on Chicory: OPA: https://github.com/StyraInc/opa-java-wasm https://github.com/StyraInc/opa-java-wasm Integration with Debezium has been launched today too: https://debezium.io/blog/2025/02/24/go-smt/ https://debezium.io/blog/2025/02/24/go-smt/ And SQLite will come next: https://github.com/roastedroot/sqlite4j https://github.com/roastedroot/sqlite4j

ncruces 2y ago
Looking forward to this reviving NestedVM's pure Java SQLite. It's only been (checks notes…) 20 years. http://nestedvm.ibex.org/ http://nestedvm.ibex.org/ https://benad.me/blog/2008/1/22/nestedvm-compile-almost-anything-to-java 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 2y ago
also the chicory Extism SDK https://github.com/extism/chicory-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 https://docs.mcp.run/tutorials/mcpx-spring-ai-java ...and Chicory works on Android too https://docs.mcp.run/tutorials/mcpx-gemini-android https://docs.mcp.run/tutorials/mcpx-gemini-android
bhelx 2y ago
Some more interesting use cases in production: Running python UDFs in Trino: https://trino.io/docs/current/udf/python.html 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 https://blog.enebo.com/2024/02/23/jruby-prism-parser.html

ertucetin 2y ago

Can we use any JVM language, like Clojure?

tombert 2y ago
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.
- evacchi 2y ago
  that is correct
bhelx 2y ago
This is distributed as just a jar, should you can invoke it from Clojure, if that is what you mean.
fulafel 2y ago
Yes, you should be able to call wasm stuffs from Clojure with it too.

nilslice 2y ago

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-android/ https://docs.mcp.run/blog/2024/12/27/running-tools-on-androi...

asimpletune 2y ago

Would Scala be able to run on this?

bhelx 2y ago
Yes i think so. it's just a jar
- andreaTP 2y ago
  Scala needs the Garbage Collection and Exception Handling proposals(afaik). They are planned but not implemented yet in Chicory.
  - bhelx 2y ago
    wait, was the question running scala in wasm or running chicory in scala?
    - andreaTP 2y ago
      To wasm or not to wasm. Well, running Chicory in Scala is seamless, I thought this comment was targeting the effort to compile Scala to Wasm in the Scala.js project.

dang 2y ago

Related. Others? Chicory 1.0.0-M1: First Milestone Release - https://news.ycombinator.com/item?id=42086590 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 https://news.ycombinator.com/item?id=38759030 - Dec 2023 (1 comment)

skyyler 2y ago

I'd like to take a moment to appreciate how cute the name is. Love stuff like that.

nilslice 2y ago
it really is a perfect name. credit to u/bhelx!
gregschlom 2y ago
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.
bhelx 2y ago
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 https://neworleanshistorical.org/items/show/1393

usrusr 2y ago

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?

andreaTP 2y ago
I would say pretty close, check this for example: https://github.com/roastedroot/sqlite4j https://github.com/roastedroot/sqlite4j

Imustaskforhelp 2y ago

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.

bhelx 2y ago
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.
gavmor 2y ago
I'd think an RPC would be the cleaner pattern, but I don't know how to deploy a service-oriented Minecraft server.

ursulasorensen 2y ago

[dead]