OpenJDK’s roadmap for JDK 28 is beginning to come into focus. The upcoming non-LTS release, scheduled for March 2027, is expected to include ahead-of-time code compilation, value objects, changes to the Shenandoah garbage collector, stricter field initialization, and a built-in JSON API.

A sixth proposal, Ahead-of-Time Code Compilation under JEP 544, has now been proposed for inclusion in JDK 28. Its goal is to reduce the time Java applications need to reach strong runtime performance.

Faster startup with AOT compilation

Java applications traditionally rely on the JVM’s just-in-time compiler to optimize code while the program runs. That approach delivers excellent long-term performance, but it can leave applications spending noticeable time warming up after startup.

JEP 544 would extend Project Leyden’s AOT cache work by allowing optimized native code to be available as soon as the HotSpot JVM starts. The proposal targets both faster startup and a shorter warmup period, without requiring changes to application code, libraries, or frameworks.

For services that restart frequently, scale rapidly, or need predictable response times immediately after deployment, this could be one of the most consequential changes in the release.

Value objects move closer

JDK 28 is also expected to introduce value objects as a preview feature under JEP 401.

Value objects are immutable and do not have object identity. Instead of being distinguished by a memory location or reference, they are defined by the values stored in their fields. This means two value objects with identical field values are considered equal.

The JVM may also represent them more efficiently than conventional objects. For developers, the feature aims to provide a cleaner model for immutable data while potentially improving memory use and performance.

Shenandoah shifts to generational mode

The Shenandoah garbage collector is expected to make generational mode its default in JDK 28. The non-generational mode would be deprecated, with removal planned for a future release rather than this one.

Generational garbage collection separates short-lived objects from longer-lived ones, allowing the collector to focus more effort on newly created objects. Making this mode the default signals that future Shenandoah development will concentrate on the generational design.

The change also reduces the maintenance burden of supporting two distinct collector modes. Applications that rely on non-generational Shenandoah will still be able to use it in JDK 28, but should begin planning for its eventual removal.

Stricter guarantees for fields

Another preview feature, strictly initialized fields, would strengthen how the JVM handles field initialization.

Under the proposal, a strictly initialized field must be assigned before it can be read. As a result, developers would never observe default values such as 0, false, or null. For fields marked final, the same value would always be observed after initialization.

This is particularly relevant for designers of JVM-based languages, which need reliable low-level guarantees around object construction and field access. The feature is intended to provide stronger integrity guarantees than Java’s current initialization model.

JSON without external libraries

JDK 28 may also include a Simple JSON API as an incubator feature.

The proposal would add a standard way to parse and generate JSON documents directly in the Java platform. Today, many Java applications depend on third-party libraries for even basic JSON handling.

The goal is not to replace every advanced JSON-processing library. Instead, the API is intended to cover common parsing and generation tasks with minimal code and no external dependency.

Platform cleanup and cryptography

JDK 28 also includes several housekeeping and developer-experience changes.

The macOS/x64 port is being deprecated for removal. Apple has largely moved its hardware to AArch64, and Oracle engineers stopped maintaining the macOS/x64 port as of JDK 27. Removing it in a future release would reduce the OpenJDK project’s maintenance workload.

The release is also expected to add PEM encodings for cryptographic objects. The API would support encoding and decoding cryptographic keys, certificates, and certificate revocation lists using the widely used Privacy-Enhanced Mail format.

What JDK 28 means for developers

JDK 28 is not an LTS release, so it will receive six months of Oracle support rather than the longer support window provided to LTS versions.

Even so, the early feature list points to meaningful progress in several areas:

• Faster application startup through AOT compilation.
• A more efficient model for immutable data through value objects.
• A clearer long-term direction for Shenandoah garbage collection.
• Stronger initialization guarantees at the JVM level.
• A standard, lightweight option for JSON processing.
• Better support for common cryptographic formats.

Because several features remain in preview or incubator status, their APIs and behavior may still change before they become standard. Developers who want to prepare for Java 28 should begin testing AOT caching, value objects, and the new JSON API in early-access builds, while avoiding production reliance on unstable features.