u/Otherwise_Sherbert21

Nowhere in my response did I advocate for AI Slop (a loaded term). You are advocating for independent thought which is what I am suggesting you use when you evaluate the project. I am not comparing an IDE to AI. I'm drawing and equivalence to demonstrate that you should be evaluating the produced artifact now how the artifact was produced.

I don't think he should have to disclose the use of AI in making this project. Are you going to "disclose" that you used an IDE? It's open source. I'm tired of people making moral judgments about code as though it's somehow AI tainted. If you're interested you can judge it yourself by inspecting the code and evaluate it on it's merits and not on how it was created.

And Claude Code is clearly listed on the Github page as a contributor so what exactly do you want?

Snode. All metal construction. I wouldn't trust anything else

I'm going to have to take a look at Hexana. I've also got some new Java+Webassembly work coming out in a little bit.

Thanks for the update. Wasmtime4J isn't an engine, it's just an API in front of other engines and supports GraalWasm and Chicory among others. It supports both JNI and Panama. Which one gets automatically picked up is going to depend on the JDK you're running but you can always specify what interface you want as long as you have a compatible JDK. --Zachary Whitley (Wasmtime4J)

It's going to be two types of people. I'm afraid there will be a larger portion of people who are absolutely lobotomized by it and a small portion who it will absolutely super charge. Mark Cuban identified this a little while ago and I think it's pretty accurate https://www.businessinsider.com/mark-cuban-two-types-of-people-using-ai-learning-lazy-2026-2?op=1

My local Afghani restaurant puts out sumac like other people put out pepper. (I don't remember seeing pepper)

Author here. You can use Wasmtime4J but you really want to be looking at Webassembly4j (https://github.com/tegmentum/webassembly4j). Happy to answer any questions. It's a single API with multiple backends. Think of it like SFL4J but for WebAssembly.

Let me know if there's anywhere I can keep an eye out for it when you finally release. I'm guessing you'll make an announcement here.

There's also WebAssembly4J https://github.com/tegmentum/wasmtime4j that gives you a uniform API for most of the runtimes mentioned.

Security, webassembly runs in a sandbox

That's going to be amazing. I'm guessing this is one of those, you think it's going to be easy until you try, types of projects. Any surprises you've come across?

This has been posted here for 22d an not a single comment? Geeze, WebAssembly has an enthusiasm problem. That's awesome and just what I've been looking for. Might save me a ton of work. Thanks.

If "We tried this once, it was a bad idea" was how we evaluated how to move forward in software design we wouldn't have any software. You can and should learn from your mistakes.

I'm a little confused about the two components that your website says it's built from:

1. An optimising Java-to-JavaScript JIT compiler.
2. A full Java SE 8 and Java SE 11 runtime based on OpenJDK.

It's just not clear what is running in webassembly and what is running in js.

Do you run in interpreted mode only or do you do C1/C2 JIT?

I've experienced the same thing and it seems particularly dramatic. I know Anthropic was doing something with discounting use during off hours so I don't know if this expiring had anything to do with it but I did go from being able to run for hours to less than an hour before hitting limits.

I've never understood the appeal of Obsidian over TiddlyWikis

I'm going to also add a hot take that with the recent developments with Anthropic and the the ease with which LLMs can discover and exploit Zero-days. The days of ambient authority are rapidly drawing to a close and I'm hoping that WebAssembly can provide at least some mitigation to that looming threat. The Log4j incident was the smoke and LLMs will be the fire.

I just recognized who you were, I really enjoyed your "The Future of Write Once, Run Anywhere" presentation. I used that talk as inspiration for some of the work. I've found that once you start pulling the webassembly thread some really interesting things start coming out with Java+Wasm.

Right now I think we are on the cusp of adoption so there are two answers. What is it being used for and what could it be used for. u/fniephaus is in a better position to talk to how it's being used now but I can say, until recently, it's been a painful process running WebAssembly from Java. Hopefully Webassemby4J helps but the component model is probably the biggest part of that. The sandbox is underrated given incidents like log4j and the coming security threat from LLMs. Database UDFs are a great application. Rewriting the same functions over and over again for every database in existence is silly and dropping in random jars that have unrestricted access to your database is unwise to say the least.

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.

Chicory is one the the supported engines....along with Wasmtime, Wamr, and GraalWasm. Chicory doesn't need a separate integration since it's already Java native and is just a jar dependency. I kept wasmtime4j and wamr4j separate so you didn't *have* to use the wasmtime4j interface and it keeps it lightweight somewhat like slf4j.

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)