WIT Bindgen and WASI · endive · Zulip Chat Archive

As touched upon in the #endive > Component Model support thread, now that the runtime support for components has reached a sufficient level (assuming my current PR lands :sweat_smile: ), I've been giving some thought to building out host-side WIT bindings that would be able to be used to implement WASI p2+ interfaces in Endive.

Ergonomically, I would like the development experience to be quite close to what Wasmtime's bindgen! macro provides. I think this is readily achievable using a Java annotation processor with a @Bindgen annotation, giving us the ability to hook in at compile time to generate the needed bindings.

The goal of the bindings is of course to reduce the amount of boilerplate code that needs to be written in order to implement the imports of a given WIT world on the host side and provide them to a guest component that targets that world. Ideally, the task of implementing the imports is reduced down to providing an implementation of a strongly typed Java interface that is generated from the WIT, and invoking the exports of a component looks as close as possible to calling any other Java class.

There are some further details to be worked out such as handling of Records and so forth, but thus far I have implemented everything necessary to replicate the bindgen! macro's examples (https://docs.wasmtime.dev/api/wasmtime/component/bindgen_examples/index.html). This would probably be the basis for an initial PR.

If the shape of this is agreed upon, then I'll finish up the remaining details of type conversion and so forth. After that, it would be feasible to use it to start working on WASI p2+.

I am currently on the fence on whether to start a full WASI implementation before starting on the async ABI features. I haven't fully wrapped my head around this, but from a quick review of the details of Wasmtime's implementation, it seems like much of WASI p2 can be implemented using the async ABI primitives internally. Thus it could be that implementing the async ABI features first could lead to a reduction in the effort needed to support both p2 and p3.

andreaTP (Sep 02 2026 at 09:54):

my bad, sorry, really swamped, I'll do my best to get things sorted by EOW.
(side note: I'll be on vacation next week)

That's really nice! I still need to look into the details, but seems a great starting point!

Regarding Wasi p2/p3, gut feeling is that Wasi p2 is the first reasonable target to get to something that is usable in real-world projects today(e.g. compiler toolchains should support it better than p3).
But I'm not a CM expert myself, and we would benefit insights from @Till Schneidereit or @Alex Crichton .

Jeremy Grelle (Sep 02 2026 at 12:27):

Yes, I agree that providing p2 support before p3 is a worthy target and we should absolutely do that. It's more a question of whether it's worthwhile to attempt it without building out the async ABI support in the runtime first.

Alex Crichton (Sep 02 2026 at 15:08):

For Wasmtime we found that implementing WASI for both wasip2 and wasip3 heavily shaped how the APIs in the wasmtime crate looked like. In that sense what I'd say is that implementing either 0.2 or 0.3 is likely to provide valuable feedback in terms of API design, runtime implementation, etc. Wasmtime's WASI implementation has the same underlying primitives but 0.2 is not implemented in terms of 0.3. We had to do refactoring to get everything extracted between them but async was different enough they didn't naturally build on top of one another as cleanly as wasip1 being implemented in terms of pretty much exactly wasip2.

Alex Crichton (Sep 02 2026 at 15:09):

It's true though that as of right now wasip2 has the broadest toolchain support between wasip2/wasip3, although the delta between the two is in theory expected to shink rapidly over the coming months

Jeremy Grelle (Sep 02 2026 at 16:14):

I believe I have a fairly decent idea at this point of the Java primitives we would use to implement the host side of the async ABI and WASI 0.3, so perhaps the thing to do would be to go ahead and start experimenting with implementation of WASI 0.2 with those same primitives where possible and leave the appropriate space for things to further evolve as async support is introduced and we then proceed to 0.3. This is essentially what I've been doing already within our runtime module, leaving space for what I have a strong sense will be needed when we get around to async support.

phoenixxo (Sep 23 2026 at 02:43):

Hi! I'm new here so I'm not sure if this is the right place to ask but I was doing some digging for solutions for running client side WASM for minecraft mods and I came upon this. I’m exploring a client bridge between the Java client & WASM for PumpkinMC. Our server runs WebAssembly components with WIT, and I'm looking into figuring out Java Minecraft client mod support to host client-side components using the same component format.

I saw on the GitHub README that WASIp2 support is still ongoing, so I wanted to ask where that was at. Does Endive currently support the WebAssembly Component Model, including WIT imports, exports, and resources along with async WIT (async func, future, and stream) and possibly WASIp3 soon?

I'm looking to find if it's possible to provide host imports for a client API and call a component’s async exports? If those pieces aren’t supported yet, is there a roadmap or an example I could look at for now? This would help me determine whether Endive could run the same kind of components we run with Wasmtime on the server.

Sorry if this message is out of place. This is my first time on zulip and this place made the most sense to post it.

Jeremy Grelle (Sep 23 2026 at 12:03):

This is very much a work-in-progress. All of the Component Model support and related functionality such as WIT bindgen and eventual WASI implementations are currently being developed in a separate repo at:
https://github.com/roastedroot/endive-cm

The idea is to get the WIT bindings generator far enough along soon to be able to use it for an implementation of WASIp2.

So basically the answer is, "not yet, but eventually". On the surface, I can't think of any reason that you wouldn't be able to do this once the full spec has been implemented. Eventual parity to be able to run the same things you can with Wasmtime is very much the idea.

As far as roadmap, you can keep an eye on https://github.com/roastedroot/endive-cm/tree/main/docs which contains an outline of the implementation plan. I've been trying to keep it fairly up-to-date with tracking the progress so far. Otherwise I'd say keep an eye on PR's and so forth if you want to stay aware of what's being worked on in the moment.

So the gist is, we're not there yet, but we've made a ton of progress already in just a few months and the momentum is still going. This is all a spare time project for me, and @andreaTP has had his hands pretty full with the main Endive project, but I'm still optimistic that we can continue to make quick progress.

andreaTP (Sep 23 2026 at 14:57):

@phoenixxo all what @Jeremy Grelle said, plus, feel free to ask here or in issues if you have any additional question :slight_smile:

phoenixxo (Sep 23 2026 at 23:49):

Thank you for the responses! Apologies I'm busy with university so I'm just seeing these.

As for Pumpkin, our next plugin API version 0.2 is focused on a stackless async architecture and implementation for the plugin runtime. So the component world uses host imports, guest exports, resources, and async WIT (async func, future, and stream). The client bridge would provide the client-side imports so a Minecraft mod could run components built against that API, hence the reason I asked the above.

I’m trying to pin down the remaining Endive work for at least this much to be working (since it is still progress towards the overall goal seemingly). Is the path roughly: finish Java bindings for imports, exports, and resource ownership; support those interactions end to end in the component runtime; then add the async Component Model machinery for functions, futures, and streams? We would only need to provide the WASI interfaces our components actually import, rather than all of WASI Preview 3. If this is the case, I'd also love to contribute or at least take a deep dive into the project (if time permits). I can see this being very useful

andreaTP (Sep 24 2026 at 10:02):

One note on the goals: our immediate target is to get to a WasiP2 working implementation, with WasiP3 and async support right after that

phoenixxo (Sep 26 2026 at 00:57):

@andreaTP I opened a PR, albeit a small change but hopefully helpful nonetheless. I'd like to continue adding more, something like loading multi-file packages ideally. Hope this is a good start!

andreaTP (Sep 26 2026 at 08:56):

Jeremy Grelle (Sep 30 2026 at 16:01):

So as of https://github.com/roastedroot/endive-cm/pull/55, we are now able to fully generate the bindings for the wasi:io@0.2.12 package. The next thing I'm going to work on is an actual implementation of the host side interfaces for wasi:io.

@andreaTP Do you have any strong opinions on how we should structure and eventually release the WASI implementations? Right now I just have a general wasi-p2 sub-module in my working branch of endive-cm, but I'm thinking we might want to treat the WASI implementation artifacts separately so that they can have their own release cycle and versioning separate from Endive itself. I think it could be desirable, for one thing, from the perspective of a consuming user to somehow incorporate the WASI package version in the version of the implementing Java artifact. ie, something like:

<dependency>
    <groupId>run.endive.wasi</groupId>
    <artifactId>wasi-io</artifactId>
    <version>0.2.12-a</version>
</dependency>

That way it is obvious how the implementation correlates to a given WASI version (the "-a" suffix is meant to leave room for bug fix releases of the implementation of a given package version). I think we'd want to keep all of the package implementations for a given WASI version in sync, so I don't think we need to get too terribly fine-grained with this...but maybe just having a separate WASI repo is warranted?

I'm undecided if this just might create too much pain from a maintenance perspective for not a huge benefit. The implementations would generally still be tied to a specific version of Endive due to the bindings generation, etc.

Whichever direction we go, I'd want to keep it in mind as I'm working on the implementation, but I don't think choosing one over the other would impact it too much.

andreaTP (Sep 30 2026 at 16:31):

On the decision ... well ... I am unsure as I don't know what we are talking about, I think that keeping things in the main repo does have advantages if they are not huge.
E.g. I would happily maintain there a wasi p2 implementation when is somewhat comparable with wasi p1

That said, I think that starting with sub-modules in the endive-cm repo should be viable today and easy to change later

Jeremy Grelle (Oct 06 2026 at 00:28):

@phoenixxo Just a heads up, as I know it's something you were looking at, that my latest PR (https://github.com/roastedroot/endive-cm/pull/58) adds initial handling in the bindgen-processor for multi-file WIT definitions. I needed it to unblock progress on WASI p2. It's fairly straightforward, as it just looks for a /deps directory next to a top-level WIT file referenced from the annotation. I am not doing any kind of advanced version resolution, etc.

phoenixxo (Oct 06 2026 at 05:31):

@Jeremy Grelle Amazing, good to see that getting done. I'd be willing to look through it whenever I get the chance. That totally makes sense, we can probably save advanced version resolution for more down the line... Sounds a bit more in-depth and complicated and like it's own chore :sweat_smile:

In the mean time, I had been doing some work around the use case I had wanted Endive / Endive-cm / Redline for and I found some things that I thought would be useful to upstream. They're in the form of three PRs, opened by me.

andreaTP (Oct 06 2026 at 13:54):

@phoenixxo I just invited you to the repo as a collaborator, this way you'll be able to review @Jeremy Grelle 's PRs :-)
I hope this way I can step out of the critical path and let you 2 proceed without having to wait for me :slight_smile:

phoenixxo (Oct 06 2026 at 18:56):

@andreaTP thanks for the invite! I accepted it, i'll look to review that hopefully by the end of the week, we'll see where my personal life and uni leave me.

casperwtf (Oct 08 2026 at 15:34):

Jeremy Grelle (Oct 08 2026 at 21:10):

@casperwtf Whilst I am always encouraged by seeing folks interested in making open source contributions, I think you would be better served to create a new discussion topic here if you'd like to discuss your work. The PRs you've linked don't appear to be at all related to WIT and WASI.

Stream: endive

Topic: WIT Bindgen and WASI

Jeremy Grelle (Sep 01 2026 at 17:34):