Skip to main content
← Back

Endive Java Wasm Host, JCO WASI P3 & the Component Model

Watch on YouTube ↗

The May 27, 2026 wasmCloud community call centers on the Wasm component model and the languages reaching it. Bailey Hayes demos Endive — the Bytecode Alliance's newly announced Java WebAssembly runtime — by building a wasmCloud host in Java that schedules workloads over NATS, and by embedding Wasm functions alongside plain Java handlers in an Eclipse Vert.x app. Victor Adossi shares that JCO 1.20 now passes all 46 upstream Wasmtime WASI P3 tests with a new Preview Three Shim, putting WASI P3 on track to launch in about two weeks, and the team walks its Q2 roadmap toward that release.

Key Takeaways​

  • Endive, a fork of the Chicory Java Wasm runtime now hosted by the Bytecode Alliance, adds a Cranelift compiler backend for a performance boost and ships as a zero-native-dependency install — but does not yet support WASI P2 or the component model
  • Endive Host is a proof-of-concept wasmCloud host written in Java that embeds Endive instead of Wasmtime, implements wasmCloud's scheduling protocol over NATS, pulls modules from an OCI registry, and was scheduled by the standard runtime operator with no awareness it was a JVM host
  • A Vert.x demo ran two plain Java handlers and two Wasm handlers behind one HTTP server in a single JVM event loop — a Java entry point composed input, handed it to a Rust-compiled Wasm markdown-to-HTML module, and merged the result with a server-side timestamp, fully sandboxed and invisible to the caller
  • For the JVM → Wasm direction, Bailey pointed to GraalVM's Web Image (native-image AOT compiler emitting Wasm) as a complementary path
  • JCO 1.20 passes 46/46 upstream Wasmtime WASI tests and ships a Preview Three Shim; you can already run P3 components authored in Rust or Python through JCO, with JavaScript-authored P3 components (via ComponentizeJS/StarlingMonkey) close behind
  • A second WASI P3 reference implementation (JCO, built with Tomas from Microsoft) passing compliance tests clears the path to launch WASI P3 in roughly two weeks; wasmCloud plans to enable P3 by default while keeping a flag to disable it
  • New docs landed: a plugin-vs-service decision framework (with comparison chart and decision tree) and an operator-oriented troubleshooting page for common deployment foot-guns
  • Benchmarking is nearly closed out — the micro-benchmark suite landed and a k6 macro benchmark is in progress; TLS and outgoing-handler work is done, leaving host component plugins and Wasm-graphics publishing as the at-risk Q2 items

Chapters​

Meeting Notes​

Endive: A Java WebAssembly Runtime from the Bytecode Alliance​

Bailey opened with a proof-of-concept built on Endive, which the Bytecode Alliance had announced as its newest hosted project the day before. Endive is a fork of the Chicory pure-Java Wasm interpreter, with the major addition of a Cranelift compiler backend for a substantial performance boost. It is packaged as a zero-native-dependency install and is designed to drop into existing JVM applications — letting teams run a WebAssembly component (written in Rust or any Wasm-targeting language) directly inside a Java process.

The important caveat: Endive does not yet support WASI P2 or the Wasm component model. The maintainers are focused on the Cranelift work plus spec-conformance items like WasmGC before tackling the component model.

Demo: Endive Host — a wasmCloud Host Written in Java​

To put Endive through its paces, Bailey built Endive Host, a wasmCloud host implemented in Java that embeds the Endive runtime where the Rust host embeds Wasmtime. It does three things: it implements wasmCloud's scheduling protocol, registering itself as a host resource over NATS (heartbeats and start/stop/status workload scheduling via the same protobuf API as the Rust host); it pulls Wasm modules from an OCI registry; and — because Endive lacks the component model — it adds a shim that invokes a WASI P1 module's _start as if it were a WASI HTTP incoming handler.

In the demo, a slightly modified wasmCloud Docker Compose brought up a Kubernetes API server (via the runtime gateway, a small Go reverse proxy, rather than full Kubernetes networking) plus a local registry. The runtime operator saw the Endive Host as healthy, Bailey pushed a hand-rolled 166-byte "hello world" Wasm module to the registry, applied a standard workload manifest into the default namespace, and curled back hello world. The key point: the operator scheduled the workload using its normal API, none the wiser that the host was a JVM rather than the Rust host — a host group could round-robin between them transparently.

Demo: Embedding Wasm in a Vert.x Java App​

Bailey argued the more compelling angle is embedding. Using the Eclipse Vert.x serverless framework, he ran five routes from a single HTTP server in one JVM: two plain Java handlers, two Wasm handlers, and a shared server. The Wasm invoker was three meaningful lines — get an Endive engine instance, load the Wasm bytes, invoke the function. He then showed a Java /render endpoint composing a request, handing it to the same Rust-built markdown-to-HTML Wasm module, and merging the output with a server-side JVM timestamp — two languages, one process, one event loop, with the Wasm fully sandboxed and the Java caller unaware it was talking to WebAssembly. For the reverse direction (existing Java compiled to Wasm), Bailey recommended GraalVM Web Image, whose native-image AOT compiler can emit Wasm.

Asked what would accelerate Endive, Bailey named component-model support as the biggest blocker — wiring up the scheduling API took "one shot and Claude in 10 minutes," but faking the P2 HTTP handler required real hackery. Full component model plus WASI P3 would unlock the broader tooling ecosystem and free language bindings. Contributors can find the maintainers in the Bytecode Alliance Zulip's Endive channel.

A Second Demo, New Docs, and the Q2 Roadmap​

Bailey gave a second quick demo of the wasmCloud OpenTelemetry example updated to the latest wasi-otel RC2, shown against an Aspire dashboard. A notable change: wasmCloud now prefixes the WASI/wasmCloud APIs implemented via host plugins (e.g. wasi:...) so generic operations like get-container or write-data no longer collide with user implementations, producing cleaner OTel spans.

Eric Gregory highlighted two new docs pages: a plugin-vs-service decision framework under the recipe guide (concept intro, comparison chart, and a decision tree for whether to extend the host with a plugin or ship a service inside a workload — closing a Q2 roadmap item), and a new operator-oriented troubleshooting page collecting common deployment foot-guns with their errors and fixes, intended as a living document fed by issues raised in Slack.

On the roadmap, Aditya's TLS and outgoing-handler work landed (and Bailey used the now-replaceable outgoing handler to de-flake a network test), the micro-benchmark suite landed with k6 macro benchmarks in progress, and the main at-risk items are host component plugins and publishing the Wasm-graphics/WebGPU runtime crate (blocked on a WebGPU dependency not yet on crates.io).

JCO, WASI P3, and the JavaScript Component Story​

Victor Adossi shared that JCO 1.20 — with major work from Tomas at Microsoft — now passes all 46 upstream Wasmtime WASI tests for P3, and ships a new Preview Three Shim package (the P3 analogue of the Preview Two Shim). You can author a P3 component in Rust, Python, or any language with P3 support (async, streams, futures) and run it through jco transpile to an ES module in Node today; authoring P3 components from JavaScript via ComponentizeJS and StarlingMonkey is "coming soon" but not yet polished.

Victor toured the wider JS-to-Wasm landscape: QuickJS (Fabrice Bellard's small JS engine) and its blessed QuickJS-ng fork underpin a Rust-bound quickjs and the Javy guest environment (which lacks component-model support); a ComponentizeJS-QJS variant now exists thanks to wit-dialib, which lets interpreted/runtime languages implement a standard FFI interface and gain component support relatively easily. The vision is for JCO to act as a toolkit spanning multiple guest-authoring options (StarlingMonkey, ComponentizeJS-QJS) and multiple host backends — including high-quality, largely vibe-coded transpilers like WC-JS that are TypeScript-first, something JCO has long wanted.

The headline: with JCO standing up as a fully compliant second reference implementation alongside Wasmtime, the team is on track to launch WASI P3 in about two weeks. wasmCloud expects to then enable P3 by default (keeping a disable flag), do a hardening pass on the P3 path, and revisit ergonomic cleanups — including possibly contributing the wasm-graphics/WebGPU suite to the Bytecode Alliance now that the WebGPU API is being revved to a native-async P3 design.

WebAssembly News and Updates​

This call is a snapshot of the WebAssembly ecosystem converging on the component model from every language at once. The Bytecode Alliance's Endive brings a Cranelift-accelerated Java runtime into the fold alongside Chicory, while GraalVM Web Image attacks the reverse JVM-to-Wasm path. On the JavaScript side, JCO, ComponentizeJS, StarlingMonkey, and the QuickJS-based experiments enabled by wit-bindgen/wit-dialib are all racing toward full WASI P3 support. With JCO now passing the upstream Wasmtime P3 test suite as a second reference implementation, WASI Preview 3 — and its native async, streams, and futures — is days away from a launch vote. For ongoing updates, follow the Bytecode Alliance and the WASI subgroup.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#, and increasingly Java) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, but as this call shows, the same scheduling protocol, OCI distribution, and workload model can be implemented by alternative hosts — like a JVM host embedding Endive. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Almost every thread in this meeting traces back to the Wasm component model. Endive is "usable today" but limited precisely because it lacks the component model — forcing Bailey's _start-as-HTTP-handler shim and blocking the free language bindings that a component-model-aware runtime would provide. JCO's milestone matters for the same reason: a second reference implementation that fully passes the WASI P3 (component-model) test suite is the gating requirement to launch Preview 3. And the component model is what makes the Vert.x demo's polyglot composition work — a Java host and a Rust-authored Wasm module interoperating through typed interfaces without either side trusting the other's internals. As more runtimes (Endive, GraalVM Web Image, QuickJS-based engines) implement the component model, the promise of "write a component once, run it in any language's host" gets closer to reality. wasmCloud's bet is that the component model becomes the universal contract across hosts, languages, and the Kubernetes-native operator that schedules them.

Who Should Watch This​

This call is especially valuable for JVM and enterprise Java teams weighing how to embed WebAssembly in existing monoliths or serverless frameworks (start with the Endive demos from 6:38), JavaScript/TypeScript developers tracking the road to running and authoring WASI P3 components in Node (Victor's JCO update at 33:20), and platform engineers deciding between extending a host with a plugin or shipping a service inside a workload (Eric's new decision-framework docs at 29:22).

Up Next​

The next community calls lead directly into the WASI P3 launch, expected in roughly two weeks. Watch for wasmCloud enabling P3 by default, a P3 hardening pass, progress on host component plugins, and the WebGPU/wasm-graphics runtime being revved for P3 — plus a possible move to contribute the wasm-graphics suite to the Bytecode Alliance.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →