From 45729b2828aa8b9fda2a13fba5f27f3b18b26d49 Mon Sep 17 00:00:00 2001 From: andreatp Date: Tue, 23 Jun 2026 13:56:38 +0100 Subject: [PATCH 1/6] docs: add Endive 1.0 release blog post Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/blog/2026-06-25-endive-1.0.md | 63 ++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 docs/blog/2026-06-25-endive-1.0.md diff --git a/docs/blog/2026-06-25-endive-1.0.md b/docs/blog/2026-06-25-endive-1.0.md new file mode 100644 index 00000000..135ead3f --- /dev/null +++ b/docs/blog/2026-06-25-endive-1.0.md @@ -0,0 +1,63 @@ +--- +slug: endive-1.0 +title: 'Endive 1.0: WebAssembly on the JVM, Now a Bytecode Alliance Project' +authors: [andreaTP] +tags: [wasm, endive, release] +--- + +We're excited to announce **Endive 1.0**, the first release of the project under the [Bytecode Alliance](https://bytecodealliance.org/). Endive is a pure-Java WebAssembly runtime with zero native dependencies, continuing the work started as Chicory. For background on the move, see the [announcement article](https://bytecodealliance.org/articles/endive-and-the-next-chapter-of-webassembly-on-the-jvm). If you're migrating from Chicory, the [migration guide](/docs/migration/from-chicory) has you covered. + + + +## WasmGC Host Integration + +Endive 1.0 redesigns how WasmGC objects are handled when they cross the boundary between Wasm and Java. Structs, arrays, and `externref` values that flow across the host boundary are now managed by the JVM garbage collector directly, instead of living in a separate store with manual lifecycle management. This makes WasmGC on the JVM feel native: GC objects behave like any other Java object. + +The annotation processor now supports `externref` as plain `Object`, so host functions work naturally with GC types without extra wiring. + +**If you pass WasmGC types across the host boundary, your code may need a small update.** The runtime surfaces clear warnings to guide you through the change. See [#55](https://github.com/bytecodealliance/endive/pull/55) for details. + +## Tail Call Optimizations + +Community-contributed fixes have improved tail call correctness, and the compiler now optimizes tail-call dispatch by eliminating unnecessary stack frame allocation. CPython 3.14, which adopted tail calls in its interpreter loop, is the main beneficiary. + +## Migrating from Chicory + +For most users, migrating is a find-and-replace. Maven coordinates move from `com.dylibso.chicory` to `run.endive`, Java packages move from `com.dylibso.chicory.*` to `run.endive.*`, and two exception classes have been renamed (`ChicoryException` to `WasmEngineException`, `ChicoryInterruptedException` to `WasmInterruptedException`). The [migration guide](/docs/migration/from-chicory) covers the full list, including Maven plugin goals, system properties, and CLI binary names. + +If you use WasmGC types at the host boundary, see the section above. + +## What's Ahead + +Community members have already started prototyping Component Model support at [endive-cm](https://github.com/roastedroot/endive-cm). Anyone interested is welcome to contribute. Follow [#52](https://github.com/bytecodealliance/endive/issues/52) for updates. Cranelift-based native compilation is also in the works, bringing near-native execution speed while preserving the pure-Java packaging experience. + +## Acknowledgements + +We'd like to thank [Dylibso](https://dylibso.com/) for creating [Chicory](https://github.com/dylibso/chicory), incubating the project through its early years, and building the community that made this transition possible. + +Thank you to every contributor who has shipped code, reported bugs, tested pre-releases, and pushed WebAssembly forward on the JVM. The [adopters list](https://github.com/bytecodealliance/endive/blob/main/ADOPTERS.md), from JRuby to Trino, from Bazel to Apache Camel, is the best evidence that this runtime is solving real problems. + +## Getting Started + +```xml + + + + run.endive + bom + 1.0 + pom + import + + + + + + run.endive + runtime + +``` + +[Documentation](https://endive.run/docs/) | [GitHub](https://github.com/bytecodealliance/endive) + +We'd love to hear what you're building. [Join the conversation on Zulip](https://bytecodealliance.zulipchat.com/#narrow/stream/endive) and let us know how it goes. From 1624763bd663fb719cd055d3b96804001b3ff0a8 Mon Sep 17 00:00:00 2001 From: andreatp Date: Fri, 26 Jun 2026 10:13:23 +0100 Subject: [PATCH 2/6] minor --- docs/blog/2026-06-25-endive-1.0.md | 59 +++++++++++++++++++++++++++++- 1 file changed, 58 insertions(+), 1 deletion(-) diff --git a/docs/blog/2026-06-25-endive-1.0.md b/docs/blog/2026-06-25-endive-1.0.md index 135ead3f..1c6462ec 100644 --- a/docs/blog/2026-06-25-endive-1.0.md +++ b/docs/blog/2026-06-25-endive-1.0.md @@ -15,7 +15,64 @@ Endive 1.0 redesigns how WasmGC objects are handled when they cross the boundary The annotation processor now supports `externref` as plain `Object`, so host functions work naturally with GC types without extra wiring. -**If you pass WasmGC types across the host boundary, your code may need a small update.** The runtime surfaces clear warnings to guide you through the change. See [#55](https://github.com/bytecodealliance/endive/pull/55) for details. +**If you use WasmGC types at the host boundary, your code will need a small update.** Here's what changed. + +GC objects (`WasmStruct`, `WasmArray`, `WasmExternRef`) are now regular Java Objects, collected by the JVM like everything else. No separate GC store, no manual lifecycle management. + +### Calling exports that use GC types + +Use `applyWithRefs` instead of `apply`. It returns a `CallResult` with separate accessors for numeric and reference results: + +```java +// Before: not possible, GC refs were opaque ints +long[] result = export.apply(args); + +// After: GC refs flow as Java Objects +CallResult result = export.applyWithRefs(new long[]{42, 10}, null); +WasmStruct point = (WasmStruct) result.refResult(0); +int x = (int) point.field(0); +``` + +Calling `apply()` on a function that involves GC types will throw. + +### Building structs and arrays + +Old constructors are deprecated. Use the builder: + +```java +// Before +var struct = new WasmStruct(typeIdx, new long[]{1, 2}); + +// After: parallel arrays indexed by field position. +// For a struct with fields (i32, ref), field 0 is numeric, field 1 is a ref. +var struct = WasmStruct.builder() + .typeIdx(typeIdx) + .fields(new long[]{42, 0}) // field 0 = 42, field 1 unused (ref) + .fieldRefs(new Object[]{null, someRef}) // field 0 = n/a, field 1 = someRef + .build(); + +int x = (int) struct.field(0); // read numeric field +Object r = struct.fieldRef(1); // read ref field +``` + +`WasmArray` follows the same pattern with `elements()` / `elementRefs()`. + +### Host functions receiving GC types + +Override `applyWithRefs` on `WasmFunctionHandle`: + +```java +WasmFunctionHandle myFunc = new WasmFunctionHandle() { + @Override + public CallResult applyWithRefs(Instance instance, long[] args, Object[] refArgs) { + WasmStruct input = (WasmStruct) refArgs[0]; + // ... process the struct + return CallResult.of(new long[]{result}, null); + } +}; +``` + +See [#55](https://github.com/bytecodealliance/endive/pull/55) for the full set of changes. ## Tail Call Optimizations From 193dcda4c567ba720d092640b8fe52e56539867a Mon Sep 17 00:00:00 2001 From: andreatp Date: Fri, 26 Jun 2026 11:29:27 +0100 Subject: [PATCH 3/6] date update --- docs/blog/{2026-06-25-endive-1.0.md => 2026-06-26-endive-1.0.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/blog/{2026-06-25-endive-1.0.md => 2026-06-26-endive-1.0.md} (100%) diff --git a/docs/blog/2026-06-25-endive-1.0.md b/docs/blog/2026-06-26-endive-1.0.md similarity index 100% rename from docs/blog/2026-06-25-endive-1.0.md rename to docs/blog/2026-06-26-endive-1.0.md From e2689ee0c54ae4704d0d86206aeae60f6192f30a Mon Sep 17 00:00:00 2001 From: andreatp Date: Fri, 26 Jun 2026 11:33:46 +0100 Subject: [PATCH 4/6] minor --- docs/blog/2026-06-26-endive-1.0.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/blog/2026-06-26-endive-1.0.md b/docs/blog/2026-06-26-endive-1.0.md index 1c6462ec..b5c4f7e0 100644 --- a/docs/blog/2026-06-26-endive-1.0.md +++ b/docs/blog/2026-06-26-endive-1.0.md @@ -90,8 +90,6 @@ Community members have already started prototyping Component Model support at [e ## Acknowledgements -We'd like to thank [Dylibso](https://dylibso.com/) for creating [Chicory](https://github.com/dylibso/chicory), incubating the project through its early years, and building the community that made this transition possible. - Thank you to every contributor who has shipped code, reported bugs, tested pre-releases, and pushed WebAssembly forward on the JVM. The [adopters list](https://github.com/bytecodealliance/endive/blob/main/ADOPTERS.md), from JRuby to Trino, from Bazel to Apache Camel, is the best evidence that this runtime is solving real problems. ## Getting Started From a8a378abfc06669259d29450203d3a4ae30064bd Mon Sep 17 00:00:00 2001 From: andreatp Date: Fri, 26 Jun 2026 11:40:35 +0100 Subject: [PATCH 5/6] docs: strengthen WasmGC JVM GC message in release post Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/blog/2026-06-26-endive-1.0.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/blog/2026-06-26-endive-1.0.md b/docs/blog/2026-06-26-endive-1.0.md index b5c4f7e0..13fb01ca 100644 --- a/docs/blog/2026-06-26-endive-1.0.md +++ b/docs/blog/2026-06-26-endive-1.0.md @@ -11,14 +11,12 @@ We're excited to announce **Endive 1.0**, the first release of the project under ## WasmGC Host Integration -Endive 1.0 redesigns how WasmGC objects are handled when they cross the boundary between Wasm and Java. Structs, arrays, and `externref` values that flow across the host boundary are now managed by the JVM garbage collector directly, instead of living in a separate store with manual lifecycle management. This makes WasmGC on the JVM feel native: GC objects behave like any other Java object. +The Java garbage collector now manages WasmGC objects. Structs, arrays, and externref values that cross the Wasm/Java boundary are standard Java Objects on the JVM heap. No separate GC store, no manual reference tracking. They get collected when unreachable, just like any other object in your application. -The annotation processor now supports `externref` as plain `Object`, so host functions work naturally with GC types without extra wiring. +The annotation processor supports `externref` as plain `Object`, so host functions work naturally with GC types. **If you use WasmGC types at the host boundary, your code will need a small update.** Here's what changed. -GC objects (`WasmStruct`, `WasmArray`, `WasmExternRef`) are now regular Java Objects, collected by the JVM like everything else. No separate GC store, no manual lifecycle management. - ### Calling exports that use GC types Use `applyWithRefs` instead of `apply`. It returns a `CallResult` with separate accessors for numeric and reference results: From 5cb96c31cf685752f620605a7add20088c12b350 Mon Sep 17 00:00:00 2001 From: andreatp Date: Fri, 26 Jun 2026 14:48:24 +0100 Subject: [PATCH 6/6] docs: use addField/addFieldRef builder API in examples Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/blog/2026-06-26-endive-1.0.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/blog/2026-06-26-endive-1.0.md b/docs/blog/2026-06-26-endive-1.0.md index 13fb01ca..32972e75 100644 --- a/docs/blog/2026-06-26-endive-1.0.md +++ b/docs/blog/2026-06-26-endive-1.0.md @@ -41,19 +41,18 @@ Old constructors are deprecated. Use the builder: // Before var struct = new WasmStruct(typeIdx, new long[]{1, 2}); -// After: parallel arrays indexed by field position. -// For a struct with fields (i32, ref), field 0 is numeric, field 1 is a ref. +// After: add fields in declaration order var struct = WasmStruct.builder() .typeIdx(typeIdx) - .fields(new long[]{42, 0}) // field 0 = 42, field 1 unused (ref) - .fieldRefs(new Object[]{null, someRef}) // field 0 = n/a, field 1 = someRef + .addField(42) // field 0: numeric + .addFieldRef(someRef) // field 1: reference .build(); int x = (int) struct.field(0); // read numeric field Object r = struct.fieldRef(1); // read ref field ``` -`WasmArray` follows the same pattern with `elements()` / `elementRefs()`. +`WasmArray` follows the same pattern with `addElement()` / `addElementRef()`. ### Host functions receiving GC types