A New Generation of Java Libraries Is Born: Wasm Becomes the Implementation Detail with Andrea Peruffo - JVM Weekly vol. 180
The new JVM Weekly is here - next Friends of OpenJDK (Foojay.io). This month: WebAssembly hiding inside your JARs, Chicory's next chapter as Endive.
As a hub for the Friends of OpenJDK (Foojay.io) continues to be one of the better places to track what is actually happening in the JVM ecosystem month-to-month. And this month’s main feature connects rather neatly to where we left off.
Last month, David Vlijmincx walked us through the sharp edges of the FFM API - VarHandle access modes, memory fences, the places where Panama makes you think like a hardware engineer. This month we get to see what happens when somebody builds an entire ecosystem on top of that machinery. Andrea Peruffo - the maintainer behind Chicory and one of the people who has done the most to make WebAssembly a first-class citizen on the JVM - published a piece arguing that we’re watching a new generation of Java libraries being born.
I’ve been following the Chicory story for a while now, and this article lands at a genuinely interesting inflection point. Let’s dig in.
A New Generation of Java Libraries Is Born: Wasm Becomes the Implementation Detail
If you’re running JRuby in production, you’re running WebAssembly. If TrinoDB is evaluating your Python UDFs, that’s WebAssembly too. If Microcks is running JavaScript dispatchers to route your mock API responses, WebAssembly is doing the work.
You didn’t install a native binary. You didn’t configure JNI. You didn’t cross-compile anything for your target platform. It just works, because the Wasm module is hiding inside a regular JAR on your classpath.
This is the same pattern that already powers the web. Every day, millions of people use Google Sheets, Figma, or Photoshop without knowing that WebAssembly is what makes those applications possible. Wasm is already invisible infrastructure in the browser. Now the same thing is happening on the JVM.
The problem every Java developer knows
Some of the best libraries in the world are written in C, C++, Rust, or Go. SQLite. QuickJS. Protocol Buffers. OPA. They are battle-tested, widely deployed, and actively maintained. At some point, every Java project wants to use one of them.
The options have never been great. You can rewrite the library in Java, but that’s expensive, error-prone, and perpetually behind the upstream. Or you can reach for JNI and ship platform-specific native binaries. That path comes with its own pain: your application becomes OS and architecture-specific. Execution leaves the safety and observability of the JVM. Distribution turns into a matrix of .so, .dylib, and .dll files. Debugging across the JNI boundary is nobody’s idea of fun. And if you’re in a restrictive environment, such as a locked-down container or a platform that blocks native library loading, JNI may not be an option at all.
For decades, this trade-off felt permanent. You could have the capability, or you could have the JVM’s guarantees. Not both.
What if the library just ran inside the JVM?
WebAssembly changes this equation. Take a proven C or Rust library, compile it to Wasm, and run it within JVM boundaries. You keep everything the JVM gives you: guaranteed memory safety, fault isolation, platform independence, advanced JIT, observability, and the “write once, run anywhere” promise. The Wasm module becomes just another artifact inside your JAR, an implementation detail that your users never need to think about.
This isn’t a theoretical possibility. It’s happening right now, in production, across a growing ecosystem of Java libraries.
The ecosystem: it’s already here
SQLite4j is a pure-Java JDBC driver for SQLite. The real SQLite, compiled to WebAssembly and embedded in a JAR. Before: you shipped platform-specific native binaries for every OS and architecture your users might run on, and hoped your CI matrix covered them all. After: one JAR, everywhere. Same SQLite, zero native dependencies. Add a Maven dependency and you have an embedded relational database.
QuickJs4j puts a full JavaScript runtime inside your Java application. QuickJS, a small, fast, standards-compliant JS engine, is compiled to Wasm and wrapped in a clean Java API. It’s already powering real production systems. Microcks, a CNCF project, uses it for JavaScript dispatchers that control how mock responses are selected based on request headers, payloads, and parameters. It works across all Microcks distributions, including native-compiled images. Before: reach for Nashorn or Rhino (both deprecated), or GraalJS (heavy dependency). After: a lightweight, sandboxed JavaScript engine in a single dependency.
pglite4j embeds PGlite, a lightweight PostgreSQL build, inside the JVM via WebAssembly. In-process, no external server, no native binaries. Useful for testing, local development, or anywhere you need Postgres compatibility without running a separate process.
Protobuf4J compiles protocol buffers without the massive native protoc toolchain. Compile-time dependencies drop from 403MB to roughly 90MB. Same output. Fraction of the footprint.
JRuby uses Prism, the Ruby parser, compiled to Wasm and consumed from Java without JNI. The JRuby team didn’t have to rewrite a parser or maintain platform-specific binaries. They added a dependency.
TrinoDB runs user-defined Python functions inside the query engine, sandboxed via WebAssembly. Users write Python UDFs; Trino executes them safely within JVM boundaries.
And the list keeps growing: Debezium single message transforms, OpenFeature flag evaluation, OPA policy engine running in-process (no network hop to an external sidecar), and more.
The pattern is always the same. Take a proven library. Compile it to Wasm. Wrap it in a JAR. Ship it on Maven Central. Your users add a dependency and get the capability. No JNI, no platform matrix, no native binary management. Wasm becomes the implementation detail.
Endive: a new chapter for WebAssembly on the JVM
This entire ecosystem was built on Chicory, a pure-Java WebAssembly runtime started in September 2023. Within two years it went from experiment to infrastructure, powering production systems across multiple organizations and proving that WebAssembly fits naturally into Java applications.
Now the project is entering its next chapter. Endive is a fork of Chicory and a Bytecode Alliance Hosted project, a vendor-neutral home where the project can grow openly. The community, the vision, and the code carry forward under the same Apache-2.0 license. What changes is that the project now belongs to its ecosystem.
Why the Bytecode Alliance? The BA is the foundation behind Wasmtime, WASI, and the Component Model: the core runtime, system interface, and component standard that define WebAssembly outside the browser. If Wasm is to become a durable cross-language component format, the JVM, one of the world’s major managed runtime ecosystems, needs to be part of that story. Endive gives the BA community a place to collaborate on JVM integration directly.
The first major milestone is integrating the experimental Redline compiler into the mainline. Redline uses Cranelift, the same compiler backend behind Wasmtime, to compile Wasm to native machine code. On Java 25+, it achieves this with zero additional dependencies, thanks to Panama’s Foreign Function & Memory API becoming a standard part of the platform. You get native-speed execution and the pure-Java packaging story.
Further out, the roadmap includes WasmGC, enabling the Java garbage collector to manage Wasm object references, and Component Model support for consuming cross-language components through typed interfaces.
For the full story on the fork, the governance model, and the migration path for existing Chicory users, see the Bytecode Alliance announcement.
Compose, don’t rewrite
The future isn’t about rewriting native libraries in Java. It isn’t about wrestling with JNI or maintaining platform-specific builds. It’s about composing your application from components written in any language (Rust, C, Go, Python, JavaScript) through WebAssembly.
One runtime. Any language. No rewrites.
Java has always been about writing code once and running it anywhere. WebAssembly extends that promise to any codebase in any language. With Endive, the JVM becomes a place where established libraries, regardless of what language they were written in, can run safely, portably, and at native speed.
Wasm becomes the invisible glue. The implementation detail that makes it all work, without you even noticing.
Get involved
The Endive repository is already available. The first release will prioritize strong continuity with Chicory, preserving compatibility and documenting migration steps clearly.
If you care about Java, WebAssembly, secure plugin systems, cross-language components, or the future of portable software, come build with us.
Also on Foojay This Month
Foojay Podcast #95: Is Your Java App Actually Secure, Or Does It Just Look That Way?
Frank Delporte (Java Champion at Azul) sat down with Steve Poole and David Welch , both from HeroDevs, for an episode of the Foojay Podcast that I’d file under “uncomfortable but necessary.”
Steve brings his concept of zombie dependencies - end-of-life libraries that look safely dormant while quietly accumulating vulnerabilities nobody will ever file a CVE against. David, co-chair of the CVE Automation Working Group, explains how the identification and disclosure process actually works - and why AI tooling is dramatically accelerating the pace at which new vulnerabilities get found, on both sides of the wall. That last clause is the one to sit with: the same automation that helps defenders triage is helping attackers prospect.
BTW: This one pairs almost suspiciously well with Steve’s CRA article below - consider them a double feature.
Context Is a Budget - Eight Levers and Three Workflow Patterns
Soham Dasgupta opens with a hook designed to get forwarded to engineering managers: a team of fifty developers can quietly burn $30,000 a month on AI coding assistants without anyone having a story for where it went. The rest of the article is the most practical treatment of AI-assistant cost discipline I’ve seen on Foojay - and I say that as someone professionally obligated to read all of them.
The mental model is in the title: stop treating the context window as a free buffet and start treating it as a budget you spend on every turn. The detail most people miss - and the article backs with research from Anthropic and Chroma - is context rot: model recall and reasoning degrade as the window fills, well inside the advertised limit. More context isn’t just expensive; past a point it’s actively harmful. The other quietly brutal number: every connected MCP server ships its full tool schemas with every request, so five servers can cost you 5,000-10,000 tokens per turn before you’ve typed a word - whether the model uses the tools or not.
The eight levers (context engineering, prompt caching, MCP hygiene, instruction files, model routing, output discipline, repo hygiene, observability) are each delivered with a “do this Monday” action, and the three workflow patterns escalate from the gloriously named Ralph Wiggum loop (cheap model + TODO.md + relentless iteration, state on disk instead of in conversation tokens) to a planner → implementer → reviewer split that routes expensive models only to the work that needs them.
None of it is rocket science, which is rather the point - as Soham puts it, most teams don’t have a token problem, they have a discipline problem. The piece already made the rounds via Baeldung’s weekly review, deservedly.
Tiberius: A Security Testing Framework for LLM Applications in Java
Iryna Dohndorf - whom regular readers may remember from last month’s anniversary podcast - opens her introduction of Tiberius with the question every team shipping LLM features eventually faces: how do you write a regression test for a system that is non-deterministic by design?
Tiberius is an open-source (Apache 2.0) Java library that answers it with a scan-fixture-validate workflow. A scan fires 200+ attack probes - jailbreaks, prompt injection, encoding evasion, data extraction, multi-turn escalation, all mapped to the OWASP LLM Top 10 - against your deployed model and serializes whatever got through to a JSON fixture. That fixture becomes version-controlled ground truth: your guardrails then get tested against attacks that actually bypassed your model, not the handful of examples a developer imagined. Both block rate and false-positive rate are first-class metrics.
Spring Boot Migration and the CRA: When Good Enough Isn’t
Steve Poole again, this time in writing, and with a date you should put in your calendar twice. The article is a follow-up to his April piece on zombie dependencies, and the framing has shifted from technical risk to legal risk: Spring Boot 3.5 reaches end of open-source support on June 30, and the EU Cyber Resilience Act starts coming into force on September 11.
The mechanics are worth knowing precisely. CRA Article 14(1): if a product you ship contains a vulnerability that’s actively being exploited and you become aware of it, you owe ENISA and your national CSIRT an early warning within 24 hours, a full notification within 72, and a final report within 14 days of a corrective measure being available. The trigger is active exploitation - not CVE assignment, not a severity score. And then you must address it “without undue delay,” a phrase that EU regulators interpret relative to what was reasonably available to you.
Here’s Steve’s sharpest point: after June 30, the upstream patch for 3.5 no longer exists - but commercial support does. Which means the regulator’s question stops being “why didn’t you take the upstream fix?” and becomes “why didn’t you use one of the available options to get a patch anyway?” Once commercial backports exist, “there was nothing we could do” stops being true. Steve works for HeroDevs and says so openly, which I appreciate - the argument holds regardless of who benefits. With the Spring community’s own guidance recommending migrations start nine to twelve months before EOL (a window that opened in July 2025), and medium codebases running 12-14 weeks, “we’ll migrate in six months” is about to become a much harder sentence to say to a regulator. A different flavor than the rest of this edition - regulation plus enterprise - but if you’re anywhere near compliance conversations, this is the one to forward.
Jakarta EE is Ready for AI – But Don’t Just Take My Word for It!
Dominika Tasarz (Senior Developer Advocate at Azul, and Frank’s new Foojay colleague as of episode #94) put together a roundup of five talks from Open Community Experience 2026 in Brussels that, taken together, make a coherent argument: enterprise Java doesn’t need framework gymnastics to do AI.
The sequencing is smart. Ivar Grimstad (Eclipse Foundation) provides the orientation talk - from J2EE’s famous pain through Jakarta EE 10/11 to the EE 12 roadmap and early AI standardization moves. Then Luqman Saeed (Azul) delivers a two-talk arc that I’d call the heart of the post: first the “intelligent monolith” - a full RAG pipeline with CDI, LangChain4j, pgvector, and Ollama, escalating all the way to in-process inference with Jlama running the model inside the JVM - and then the microservices variant, where Jakarta Data repositories store embeddings as plain JPA byte arrays with cosine similarity in plain Java, and Jakarta Concurrency 3.1’s virtual threads handle the I/O-bound inference work. What Dominika rightly highlights is Luqman’s honesty about limits: in-memory vector search works until it doesn’t, and he tells you what signals mean it’s time for a real vector database.
Kenji Kazumura (Fujitsu) then asks the production question - supervisor agents coordinating sub-agents over MCP, with JWT propagation, OpenTelemetry tracing, and compensation patterns where ACID can’t reach - and introduces the Jakarta Agentic AI project aiming to standardize agent lifecycle across the ecosystem. Rustam Mehmandarov closes with the necessary cold shower: all of these agents talk over APIs, and your AI architecture is worth very little if those APIs are fragile and badly versioned.
Five talks, all with recordings embedded, and a useful counterweight to the assumption that “Java + AI” automatically means Spring.
And that’s all, folks.
PS: JDD in Krakow is looking for speakers! We’re looking for in Call for Papers submissions. 🧠
👉 We’re accepting them until June 21