JDK 27, the second non-LTS release since JDK 25, has reached its first release candidate as declared by Mark Reinhold, Chief Architect, Java Platform Group at Oracle. The main-line source repository, forked to the JDK stabilization repository in early-June 2026 (Rampdown Phase One), defines the feature set for JDK 27. Critical bugs, such as regressions or serious functionality issues, may be addressed, but must be approved via the Fix-Request process. As per the release schedule, JDK 27 will be formally released on September 15, 2026.
The final set of nine (9) new features, in the form of JEPs, can be separated into four (4) categories: Core Java Library, HotSpot, Security Library and Java Language Specification.
Three (3) of these new features are categorized under Core Java Library:
- JEP 531: Lazy Constants (Third Preview)
- JEP 533: Structured Concurrency (Seventh Preview)
- JEP 537: Vector API (Twelfth Incubator)
Three (3) of these new features are categorized under HotSpot:
- JEP 523: Make G1 the Default Garbage Collector in All Environments
- JEP 534: Compact Object Headers by Default
- JEP 536: JFR In-Process Data Redaction
Two (2) of these new features are categorized under Security Library:
- JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
- JEP 538: PEM Encodings of Cryptographic Objects (Third Preview)
And finally, one (1) of these new features is categorized under Java Language Specification:
We examine some of these new features and include where they fall under the auspices of the major Java projects - Amber, Loom, Panama, Valhalla and Leyden - designed to incubate a series of components for eventual inclusion in the JDK through a curated merge.
Project Amber
JEP 532, Primitive Types in Patterns, instanceof, and switch (Fifth Preview), proposes a fifth preview, with two changes, after four rounds of preview delivered in JDK 23 through JDK 26. This feature enhances pattern matching by allowing primitive types in all pattern contexts, and extending the instanceof and switch constructs to work with all primitive types. Changes include: enhance the definition of unconditional exactness; and the application of tighter dominance checks in switch constructs.
Project Loom
JEP 533, Structured Concurrency (Seventh Preview), proposes a seventh preview, with minor changes, after six rounds of preview delivered in JDK 21 through JDK 26 and two rounds of incubator delivered in JDK 19 through JDK 20. This feature simplifies concurrent programming by introducing structured concurrency to "treat groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability."
Project Panama
JEP 537, Vector API (Twelfth Incubator), proposes a twelfth incubation, with no substantial implementation changes since JDK 25, after eleven rounds of incubation delivered in JDK 16 through JDK 26. This feature introduces an API to "express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations." The Vector API will continue to incubate until the necessary features of Project Valhalla become available as preview features. At that time, the Vector API team will adapt the Vector API and its implementation to use them, and will promote the Vector API from Incubation to Preview.
Security Library
JEP 538, PEM Encodings of Cryptographic Objects (Third Preview), proposes a third preview after two rounds of preview delivered in JDK 25 and JDK 26. This feature offers "an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the widely-used Privacy-Enhanced Mail (PEM) transport format, and for decoding from that format back into objects." This JEP will support conversions between PEM text and cryptographic objects in PKCS #8 and X.509 binary formats. Changes include: a reclassification of the PEM record class to a regular class as a convenience for providing constructors that accept Base64-encoded content in byte arrays; and a rename of the DEREncodable interface to BinaryEncodable to more accurately describe the binary data stored in PEM text.
HotSpot
JEP 536, JFR In-Process Data Redaction, proposes to enhance the JDK Flight Recorder (JFR) to redact sensitive information before the JFR completes its recording. This data may include command-line arguments, initial values of environment variables and system properties.
JEP 534, Compact Object Headers by Default, proposes to make JEP 519, Compact Object Headers, delivered in JDK 25, the default object header layout in the HotSpot JVM. More details on Compact Object Headers may be found in this InfoQ news story.
JEP 523, Make G1 the Default Garbage Collector in All Environments, proposes to set the Garbage-First Garbage Collector (G1 GC) as the "default in all environments, rather than just server environments." If a garbage collector is not specified on the command line, the G1 GC will always be selected by the HotSpot JVM.
JDK 28
Scheduled for a GA release in March 2027, six (6) JEPs (five Targeted and one Proposed to Target) will be included in JDK 28 at this time. We will also surmise which JEP candidates and drafts have the potential to be included in JDK 28 especially those that have been submitted or an incremental preview.
JEP 541, Deprecate the macOS/x64 Port for Removal, has been Targeted for JDK 28. This JEP proposes to deprecate the macOS/x64 port as Apple no longer supports this architecture. Similar to JEP 449, Deprecate the Windows 32-bit x86 Port for Removal, the intent to remove this port in a future release to save on maintenance costs.
JEP 540, Simple JSON API (Incubator), has been Targeted for JDK 28. This JEP defines a simple, standard API for parsing and generating JSON documents without the need for an external library. This feature implements RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format, and supersedes JEP 198, Light-Weight JSON API, which is now closed and withdrawn.
JEP 539, Strict Field Initialization in the JVM (Preview), has been Targeted for JDK 28. This JEP introduces strictly-initialized fields in the Java Virtual Machine that are required to be initialized before they are read. Therefore, default values such as 0 or null are never observed. This feature is available for use by compilers that emit class files.
JEP 535, Shenandoah GC: Generational Mode by Default, has been Targeted for JDK 28. This JEP proposes to designate the Shenandoah Garbage Collector to generational mode by default. The non-generational mode will be deprecated with the intent to remove it in a future release.
JEP 401, Value Objects (Preview), has been Targeted for JDK 28. Formerly known as Object Classes and Values (Preview), this JEP proposes to enhance the language with value objects, defined as objects that: only contain final fields; do not have identity; and are solely distinguished by the values of their respective fields. More details on JEP 401 may be found in this InfoQ news story.
JEP 542, PEM Encodings of Cryptographic Objects, has been Proposed to Target for JDK 28. This JEP proposes to finalize this feature after three rounds of preview delivered in JDK 25 through JDK 27. This feature offers "an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the widely-used Privacy-Enhanced Mail (PEM) transport format, and for decoding from that format back into objects." This JEP will support conversions between PEM text and cryptographic objects in PKCS #8 and X.509 binary formats. Changes include: a reclassification of the PEM record class to a regular class as a convenience for providing constructors that accept Base64-encoded content in byte arrays; and a rename of the DEREncodable interface to BinaryEncodable to more accurately describe the binary data stored in PEM text.
JEP Draft 8389764, Lazy Constants (Fourth Preview), proposes a fourth preview, with no changes, after three rounds of preview delivered in the upcoming release of JDK 27 and JDK 26 through JDK 25. Formerly known as Stable Values and Computed Constants, this feature introduces the concept of computed constants, defined as immutable value holders that are initialized at most once. This offers the performance and safety benefits of final fields, while offering greater flexibility as to the timing of initialization. The name change from Stable Values to Lazy Constants with the release of JDK 26, better captures the intent of a high-level use case.
JEP Draft 8329758, Faster Startup and Warmup with ZGC, proposes to enhance the Z Garbage Collector to more efficiently allocate memory in response to the needs of an application. Startup time can be minimized by creating only a small initial heap that reduces the overhead of the operating system.
Please note that draft JEPs may be subject to change at any time. We anticipate that Oracle will target additional JEPs for JDK 28 very soon.