JEP 535 Targeted: Generational Shenandoah Becomes the Default in JDK 28
JEP 535, "Shenandoah GC: Generational Mode by Default," has moved to Targeted for JDK 28. The change is small in code but significant in behaviour: the default value of ShenandoahGCMode switches from satb to generational. From JDK 28, plain -XX:+UseShenandoahGC runs Generational Shenandoah, while explicitly selecting -XX:ShenandoahGCMode=satb still runs the classic single-generation collector but prints a deprecation warning. The non-generational mode is not removed yet — the JEP only deprecates it with the intent to remove it in a later release.
The motivation is twofold. Generational mode collects young objects frequently and old objects rarely, which the JEP says gives lower concurrent overhead, better allocation throughput and a smaller memory footprint for most workloads. And maintaining two Shenandoah modes in parallel has been slowing down new feature work in the collector.
For teams running Shenandoah in production, the practical work is mostly in tooling: GC log output and the data exposed via serviceability and management APIs may differ, and anything that parses JVM output could trip over the new warning. Teams that depend on the old mode for a specific latency profile should pin -XX:ShenandoahGCMode=satb explicitly now and start benchmarking the generational mode on JDK 28 early-access builds.
Read more — OpenJDK
JDK 28 Feature Set Grows to 10 Targeted JEPs, Including Final Structured Concurrency
The JDK 28 project page now lists ten JEPs as targeted. Beyond JEP 535, the most notable status change since last week is that the three JEPs that were Proposed to Target in early October — JEP 543 (Structured Concurrency), JEP 545 (Faster Startup and Warmup with ZGC) and JEP 546 (Adaptive Heap Sizing for ZGC) — all completed their review periods and are now formally Targeted. JEP 543 finalizes StructuredTaskScope without change after two incubator rounds (JDK 19–20) and seven previews (JDK 21–27), so code written against the JDK 27 preview API should compile on JDK 28 without --enable-preview.
The full targeted list is now: JEP 401 Value Objects (Preview), JEP 535 Generational Shenandoah by default, JEP 539 Strict Field Initialization in the JVM (Preview), JEP 540 Simple JSON API (Incubator), JEP 541 Deprecate the macOS/x64 Port for Removal, JEP 542 PEM Encodings of Cryptographic Objects, JEP 543 Structured Concurrency, JEP 544 Ahead-of-Time Code Compilation, JEP 545 and JEP 546.
Waiting in the wings, JEP 547, Lazy Constants (Fourth Preview), moved from draft to Candidate. The API — formerly known as Stable Values and Computed Constants — provides immutable values that are initialized at most once, and this round proposes a fourth preview with no API changes. JDK 28 early-access Build 19 is also available for testing.
Read more — OpenJDK
Helidon 27 Adopts Oracle's Tip and Tail Model With New Messaging and Data Modules
Helidon 27 is the first release of Oracle's microservices framework to follow the "Tip & Tail" model of library development. Helidon 27 is the tip, aligned with JDK 27 and released on the OpenJDK cadence (Helidon 28 is expected alongside JDK 28 in March 2027). Helidon 4.5.5 is the tail: it stays on the 4.5 LTS line with a JDK 21 baseline, adds JDK 25 support, and receives only critical fixes, security patches and selected backports.
The programming models were restructured. Helidon Core replaces Helidon SE and offers two styles: an imperative model in plain Java with no injection or annotations, and a declarative model using dependency injection and annotations whose wiring is generated at build time. Helidon MicroProfile replaces Helidon MP and moves into its own project, while the former SE Integrations become Helidon Extensions with independent release lifecycles.
Two new modules stand out. Helidon Messaging offers a blocking (rather than reactive) messaging layer — natural on virtual threads — with Kafka, JMS and Apache Pulsar connectors bound through configuration. Helidon Data JDBC provides a repository-query API whose query interfaces are turned into implementation classes at compile time, and supports Jakarta Persistence via EclipseLink and Hibernate ORM.
Read more — InfoQ
Java Ecosystem Roundup: Open Liberty on JDK 27, LangChain4j 1.22, Micronaut Netty CVE Fixes
InfoQ's roundup for the week of October 5 collected a busy set of ecosystem releases. Open Liberty 26.0.0.10 reached GA with JDK 27 support and fixes for seven CVEs; because JDK 27 makes G1 the default collector in all environments, the release notes warn that containers with constrained resources may see different GC behaviour than on earlier Java versions.
LangChain4j 1.22.0 added a BedrockBatchChatModel that implements BatchChatModel on top of the Amazon Bedrock batch inference API, plus OpenAiDecisionModel and OpenAiOfficialDecisionModel for OpenAI's new Decisions API. Micronaut 5.2.2 upgrades Netty to 4.2.19.Final, resolving 16 CVEs including HTTP request/response smuggling and unbounded resource consumption in the HTTP/1, HTTP/2 and HTTP/3 codecs — a patch worth applying promptly.
Other releases: Infinispan 16.3.0 improves hash-based conflict resolution when merging partitions and persists configuration attributes across restarts; GlassFish 8.0.5 speeds up deployments and fixes ZIP64 extra-field headers; and TornadoVM 7.2.0 adds mmaLoadA()/mmaLoadB() matrix-multiply fragment loaders for HalfFloat and more accurate CUDA dispatch timing.
Read more — InfoQ
Links & Sources
You May Also Enjoy
