Java News Roundup – May 11 2026: JDK 27 JEPs, Azul Payara Rebrand, WildFly wado CLI, LangChain4j 1.15, OpenXava 7.7.2 and Google ADK 1.3

What changed this week

• OpenJDK JEPs – JEP 523 (make G1 the default GC), JEP 534 (compact object headers), JEP 537 (Vector API twelfth incubation) and JEP 538 (PEM encoding API) were all promoted to Proposed status for the upcoming JDK 27 release. The review deadline is May 19, 2026.
• Azul Payara – The community edition is now marketed as Azul Payara Community. The May 2026 release (7.2026.5) adds Jakarta EE 11 support, updates the JAAS provider chain and removes legacy managed‑executor descriptors.
• WildFly wado – A brand‑new command‑line tool written in Rust, wado, simplifies building and running WildFly containers in both domain and standalone modes.
• LangChain4j 1.15.0 – Brings a Docling document parser integration and a defaultValue() attribute for LLM‑tool annotations.
• OpenXava 7.7.2 – Improves AI‑assisted code generation via an updated AGENTS.md and adds a one‑line dashboard prompt.
• Google ADK 1.3.0 – Introduces a ChatCompletionsHTTPClient for Apigee‑backed chat completions and a flexible SkillSource loader.
• Micronaut 4.10.14 – Patch release that upgrades Netty to 4.2.13, fixing more than a dozen CVEs.

---

Provider comparison and migration considerations

Feature	Azul Payara Community	WildFly (standard)	OpenJDK 27 (default)
Default GC	G1 (via JEP 523) – low‑pause, suitable for both micro‑services and monoliths	Uses whatever GC the JVM supplies; historically defaults to ParallelGC	G1 becomes the universal default, removing the need for -XX:+UseG1GC flags
Memory layout	Compact object headers (JEP 534) reduce object size by up to 12 % on 64‑bit HotSpot	No automatic header compaction; developers must enable -XX:+UseCompressedOops manually	Compact headers are now the baseline, benefiting all Java applications, including Payara and WildFly
Vector processing	No built‑in vector API; can depend on external libraries	Same limitation; projects often embed the incubating Vector API manually	JEP 537 makes a stable Vector API available, allowing high‑throughput numeric workloads without native code
Cryptography handling	Relies on standard JCA; PEM support limited to third‑party libs	Same as Payara	JEP 538 adds first‑class PEM encoding/decoding, simplifying key‑management pipelines
Container tooling	No dedicated CLI; typical Dockerfile approach	jboss-cli.sh for remote management, but container orchestration is manual	wado (Rust) provides opinionated defaults for naming, ports and credentials, reducing Dockerfile boilerplate
Migration effort	Upgrade from Payara 6 → 7 requires updating deployment descriptors for Jakarta EE 11 and switching JAAS provider classes. No breaking API changes, but test suites should verify the new DefaultPolicy integration.	Moving to wado does not require code changes; it replaces the Docker build step. Existing WildFly archives can be imported directly.	Applications compiled for JDK 25/26 will run unchanged. To benefit from G1 defaults and compact headers, rebuild with JDK 27 and run the full test suite, especially if you rely on object‑size assumptions.

Strategic takeaways

• Performance – Enterprises that have struggled with GC pause spikes will see immediate benefits from G1 becoming the default. The change eliminates a common source of production incidents and reduces the operational overhead of tuning GC flags.
• Footprint – Compact object headers shrink heap usage, which translates into lower cloud‑instance costs for large‑scale services. The benefit is most pronounced for data‑intensive workloads (e.g., in‑memory caches, streaming analytics).
• AI‑enabled tooling – The LangChain4j and Google ADK updates lower the barrier to integrate LLM‑driven features. The defaultValue() annotation helps avoid runtime failures when an LLM does not emit an expected argument, a practical improvement for production agents.
• Container ops – wado positions WildFly as a more cloud‑native runtime. Its Rust implementation brings fast start‑up and a small binary footprint, which aligns with the trend toward lightweight JVM containers.
• Vendor lock‑in – Azul’s rebranding of Payara clarifies the product roadmap: community users stay on a fully open source stack, while enterprise customers can migrate to Azul Payara Enterprise for commercial support. This separation reduces uncertainty for long‑term roadmap planning.

---

Business impact

1. Cost optimisation – Switching to JDK 27 on production workloads can cut GC‑related CPU consumption by 10‑15 % and reduce heap pressure by up to 12 % thanks to compact headers. For a typical 100‑node micro‑service fleet, that equates to a noticeable reduction in cloud spend.
2. Risk mitigation – The new PEM API (JEP 538) standardises key handling across services, reducing the chance of mis‑configuration that leads to TLS failures. Teams can now store certificates in PEM files and rely on the JVM to parse them securely.
3. Speed to market for AI features – LangChain4j 1.15 and Google ADK 1.3 provide ready‑made adapters for document parsing and chat‑completion APIs. Companies can prototype LLM‑backed assistants in weeks rather than months, accelerating product innovation.
4. Operational simplicity – wado abstracts away much of the container‑orchestration boilerplate. Teams that already use Kubernetes can adopt the tool without rewriting Helm charts, shortening the CI/CD pipeline for WildFly‑based services.
5. Vendor strategy – The Azul Payara rebrand signals a tighter integration with the broader Azul ecosystem (Zulu, Prime, Intelligence Cloud). Organizations evaluating a move away from Oracle‑supported Java runtimes now have a clear, commercially backed path that includes both community and enterprise tiers.

---

Next steps for architects

• Run a pilot on a non‑critical service with JDK 27 to measure GC pause distribution and heap usage before committing to a full rollout.
• Evaluate wado by converting an existing WildFly Dockerfile; compare image size and start‑up latency against the current approach.
• Update CI pipelines to pull the latest LangChain4j and Google ADK artifacts; add unit tests for the new defaultValue() handling.
• Plan a migration checklist for Payara users: verify Jakarta EE 11 compatibility, replace JAAS provider classes, and test the new deployment descriptors.
• Engage with Azul if you need extended support for macOS x64 or want a guaranteed upgrade path beyond JDK 27.

---

For deeper technical details, consult the official JEP pages, the Azul Payara release notes, the WildFly wado repository, and the LangChain4j/Google ADK changelogs.