JEP 543: Structured Concurrency Proposed to Target JDK 28 as a Final Feature
JEP 543 has been Proposed to Target for JDK 28, and its stated goal is to finalize Structured Concurrency "without further change." The API first arrived as an incubator in JDK 19 (JEP 428), became a preview in JDK 21 (JEP 453), and was re-previewed in every release since. The final rounds of API reshaping are what make this finalization plausible: JDK 25 (JEP 505) replaced public constructors with static open(...) factory methods, and JDK 27 (JEP 533) added a type parameter for the exception thrown by join(). The review period ends on October 13.
The finalized shape is StructuredTaskScope<T, R, R_X>, where T is the subtask result type, R is what join() returns and R_X is the exception join() can throw. The usual workflow is to open a scope in a try-with-resources block, fork subtasks, join them as a unit, and then read results through Subtask::get, which throws if called before join. The default open() policy fails the whole scope if any subtask fails, while built-in joiners such as anySuccessfulOrThrow(), allSuccessfulOrThrow(), awaitAllSuccessfulOrThrow() and allUntil(Predicate) cover the common fan-out and race patterns. Custom joiners implement onFork, onComplete, result and timeout.
The parts that make this more than a nicer ExecutorService are the enforced structure and observability. Subtasks inherit ScopedValue bindings, forking from a non-owner thread fails, improper nesting throws StructureViolationException, and closing a scope cancels and waits for any outstanding subtasks. JSON thread dumps (jcmd <pid> Thread.dump_to_file -format=json) show scopes and their threads as a tree, which is a real debugging win for virtual-thread-heavy services. Once JDK 28 ships, teams that avoided preview flags in production can finally adopt the API without --enable-preview.
Read more — OpenJDK
JEPs 545 and 546: ZGC Gets Faster Startup and Adaptive Heap Sizing
Two companion ZGC proposals by Erik Österlund were also Proposed to Target for JDK 28, both enabled with -XX:+UseZGC -XX:+ZAdaptiveHeapSizing. JEP 545 (Faster Startup and Warmup with ZGC) changes how the heap grows at startup: ZGC now commits only 2MB initially, then expands aggressively in successively larger steps when collections become frequent. Expansion is done by GC worker threads capped at 25% of CPU threads, and those workers also pre-touch newly committed pages concurrently and, on Linux 6.1+, upgrade small pages to large pages without kernel configuration. Memory is managed in 2MB units instead of 4KB.
The JEP's Spring PetClinic case study on a 32GB machine shows why this matters. With a small heap and no pre-touch on JDK 25, startup took 5.86s but warmup took around 80s; with a 20GB pre-touched heap, warmup finished within 10s but startup grew to 9.45s. The proposed configuration gets 5.84s startup and warmup within 10s, and the JEP claims roughly 40% lower startup and 90% lower warmup overall. The ablations are telling: without concurrent pre-touching warmup takes 34s, and without large pages it takes 18s.
JEP 546 (Adaptive Heap Sizing for ZGC) handles the steady state. When enabled, the default maximum heap becomes 100% of physical memory minus a small reserve (up from 25%), and ZGC grows or shrinks the heap to hit a target GC CPU usage set by -XX:ZGCIntensity=N (default 5; lower means less CPU, more memory). It also rebalances young and old generations and acts as a "good neighbour", contracting when host memory is tight and CPU is idle. In the case study, three JVMs sharing a 16GB container converged to an even memory split within about two minutes. Together, the two JEPs aim to make -Xms, -Xmx and -XX:+AlwaysPreTouch unnecessary for most ZGC deployments, though the JEPs warn that apps tuned for a large initial heap may need retuning.
Read more — OpenJDK
Pooled Confined Arenas Make Small FFM Allocations Up to 18x Faster in JDK 28
An Inside Java post details a JDK 28 change to the Foreign Function & Memory API: small allocations from Arena.ofConfined() can now be served from reusable native-memory pools instead of going to malloc and free every time. Each platform thread keeps a small cache of pools (by default up to four 64-byte pools). An arena acquires one lazily on its first poolable allocation, carves small allocations from it sequentially, and on close zeroes the used portion and returns the pool to the cache. Allocations that don't fit or need unsupported alignment fall back to the regular allocator, and virtual threads briefly borrow a pool from their carrier so they can still migrate while the arena is open.
The reported speedups for tiny allocations are large: 5-byte allocations ran 12.3x faster on Linux AArch64, 6.8x on Linux x64, 18.6x on macOS AArch64 and 16.8x on Windows x64. On an Apple M4, a 5-byte allocation dropped from about 15.9 ns/op to 1.05 ns/op. Allocations above the 64-byte pool size were roughly at parity with the old path.
No source changes are needed, and segment lifetime and access semantics are unchanged. The biggest beneficiaries are jextract-style bindings that make frequent, tiny native calls with pointer out-parameters, small C structs or short strings. One practical caveat for tool authors: diagnostics can no longer assume a one-to-one mapping between arena allocations and native malloc/free calls.
Read more — Inside Java
InfoQ Roundup: JEP 544 AOT Code Compilation Targeted, JobRunr 9, Micronaut 5.2, LangChain4j Decision Models
InfoQ's roundup for the week of September 28 reports that JEP 544, Ahead-of-Time Code Compilation, has moved from Proposed to Target to Targeted for JDK 28. It extends the Leyden AOT cache work so applications can start with optimized native code already available, reaching peak performance sooner. JDK 28 early-access Build 18 also shipped. On the Jakarta EE side, the planned Jakarta EE 12 timeline is Core Profile on December 1, Web Profile on March 31 and the full Platform on May 15.
Framework releases were busy:
- JobRunr 9.0.0 GA adds a Gantt-style Chart tab for job history (rows per state and per durable step) and support for Micronaut 5 and Quarkus 3.40.
- Micronaut 5.2.0/5.2.1 introduces an experimental Micronaut for Python module that processes Python source at compile time, plus a new Jakarta Expression Language module.
- LangChain4j 1.21.0 adds an experimental decision-model API (
DecisionModel,DecisionServices,RoutingChatModel,DecisionRouterPlanner), bringing the "choose among typed options" model class into Java agent code. - Eclipse JNoSQL 1.19.0 graduates to a full EE4J project and adds ScyllaDB support.
- OpenXava 8.0.0 is now built on Spring Boot.
- Google ADK for Java 1.11.0 adds thread-safe session event methods, replacing the deprecated
events().
The roundup also introduced Lathe 0.1.14, a new Java Language Server that derives its project model directly from the Maven build instead of a separate import step. It works with any LSP-capable editor and ships with a Neovim client and an MCP server so AI coding agents can query the same semantic model.
Read more — InfoQ
IntelliJ IDEA's Java and Kotlin LSP Extension Reaches Release Candidate
JetBrains' "Java and Kotlin by IntelliJ IDEA" extension, which brings IntelliJ's Java and Kotlin analysis to VS Code-based editors over LSP, has reached Release Candidate about two months after its preview. It is distributed through both the Visual Studio Marketplace and Open VSX, so it works in VS Code, Cursor and other forks, and has passed 20,000 downloads.
The extension provides IntelliJ's completion, navigation, inspections and quick-fixes, project-wide refactorings, DAP-based debugging, Maven/Gradle/Bazel project import, built-in test running and Spring tooling interoperability. Notably, Cursor's agent can use the same language server for semantic code search and navigation, which gives AI agents in those editors IntelliJ-grade Java understanding rather than text search.
The RC is the final EAP build and can be used for 30 days without a license. After the stable 1.0 release, which JetBrains says is "very soon", new users get a 30-day trial and then need an IntelliJ IDEA Ultimate subscription. For teams that standardised on VS Code-family editors for AI tooling but missed IntelliJ's Java analysis, this is the first commercially supported way to combine the two.
Read more — JetBrains
Links & Sources
- JEP 543: Structured Concurrency
- JEP 545: Faster Startup and Warmup with ZGC
- JEP 546: Adaptive Heap Sizing for ZGC
- Making Arena.ofConfined() Even Cheaper in JDK 28
- Java News Roundup: JobRunr 9, OpenXava 8, Quarkus, LangChain4j, JNoSQL, Introducing Lathe
- Java and Kotlin by IntelliJ IDEA: The LSP-Based Extension Reaches Release Candidate
- JDK 28 project page
You May Also Enjoy
