What’s New in JDK 27: Features, JEPs, and Architectural Enhancements

Released on September 15, 2026, JDK 27 continues Java’s six-month release cadence following JDK 26 and Java 25 (LTS). As the Reference Implementation of Java SE 27 under JSR 402, JDK 27 delivers nine official JDK Enhancement Proposals (JEPs) along with landmark performance and security advancements.

Among the headline changes are Compact Object Headers turned on by default (Project Lilliput), G1 becoming the universal default garbage collector across all environments, native Post-Quantum Hybrid Key Exchange for TLS 1.3, and in-process data redaction for JDK Flight Recorder (JFR).

Here is an exhaustive guide to everything included in JDK 27.

At a Glance: The 9 JEPs of JDK 27

1. Landmark Runtime & Memory Advances

JEP 534: Compact Object Headers by Default

A historic milestone from Project Lilliput, JDK 27 enables Compact Object Headers by default on supported 64-bit architectures (x64 and AArch64).

The Problem

Historically, every object on the 64-bit HotSpot JVM carried an object header overhead of 96 to 128 bits (comprising a 64-bit mark word and a 32-bit compressed or 64-bit uncompressed klass pointer). In applications with hundreds of millions of small objects (such as strings, wrappers, nodes, or domain entities), object headers consumed up to 20%–30% of total heap memory.

The Solution in JDK 27

Compact Object Headers condense the object header down to a single 64-bit mark word, encoding both the object metadata (hash code, locking state, age bits) and the compressed class pointer into one unified layout.

Traditional 64-bit Header (96 to 128 bits):
+----------------------------------+-----------------------+
|            Mark Word             |    Klass Pointer      |
|             (64 bits)            |   (32 or 64 bits)     |
+----------------------------------+-----------------------+

JDK 27 Compact Object Header (64 bits total):
+----------------------------------------------------------+
|       Combined Mark Word + Compressed Class Pointer      |
|                         (64 bits)                        |
+----------------------------------------------------------+

Real-World Impact

• Heap Footprint Reduction: Real-world applications typically see an immediate 10% to 20% reduction in live heap memory without code modifications.
• Improved CPU Cache Density: Smaller objects translate to higher $L1/L2/L3$ cache line utilization, yielding noticeable throughput gains on data-intensive workloads.
• Fallback Flag: If legacy tooling or low-level agents experience incompatibility with native offsets, compact headers can be disabled using:-XX:-UseCompactObjectHeaders

JEP 523: Make G1 the Default Garbage Collector in All Environments

Since JDK 9, the Garbage-First (G1) collector has been the default GC for “server-class” machines (systems with at least 2 CPU cores and 2 GB of RAM). However, on resource-constrained containers or single-core virtual machines, HotSpot previously reverted to the single-threaded Serial GC.

What Changes in JDK 27

JEP 523 removes the environment distinction: G1 is now the default collector for all JVM instances, regardless of core count or memory size.

• Why? Advances in G1 (including the write-barrier synchronization overhauls completed in JDK 26) have reduced its baseline memory overhead and latency jitter to the point where it consistently matches or outperforms Serial GC even in constrained cloud containers.
• Consistency: Eliminates unexpected behavioral and performance divergence when containerized microservices transition between low-resource development instances and production environments.
• Manual Override: For embedded or ultralight CLI applications where minimal memory usage supersedes parallel throughput, Serial GC remains available via:-XX:+UseSerialGC

2. Post-Quantum Cryptography & Enterprise Security

JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3

With quantum computers rapidly progressing toward breaking standard asymmetric cryptography (RSA, ECDHE), organizations face the threat of “Harvest Now, Decrypt Later” attacks—where adversaries intercept and store encrypted traffic today to decrypt it once quantum resources become available.

JEP 527 integrates standardized post-quantum hybrid key exchange schemes into the native Java TLS 1.3 implementation:

• Hybrid Mechanisms Supported:
  • X25519MLKEM768 (Combines classical X25519 with ML-KEM-768 / FIPS 203)
  • SecP256r1MLKEM768 (Combines classical ECDHE NIST P-256 with ML-KEM-768)

How It Works

The hybrid approach combines a classical key agreement algorithm with a post-quantum algorithm. An attacker must break both underlying mathematical problems simultaneously to compromise the session keys.

import javax.net.ssl.SSLParameters;
import javax.net.ssl.SSLSocket;

// Inspecting or configuring TLS 1.3 Named Groups
SSLParameters params = sslSocket.getSSLParameters();

// Hybrid post-quantum algorithm is negotiated automatically when both endpoints support it
params.setNamedGroups(new String[] { 
    "X25519MLKEM768", 
    "x25519", 
    "secp256r1" 
});
sslSocket.setSSLParameters(params);

HotSpot activates hybrid post-quantum groups by default when negotiating TLS 1.3 connections, requiring zero boilerplate code for standard HttpClient, SSLSocket, and HTTP microservice servers.

JEP 536: JFR In-Process Data Redaction

Java Flight Recorder (JFR) is an indispensable diagnostic and performance tracing tool. However, production dumps often inadvertently capture sensitive personal identifiable information (PII), API tokens, passwords, or cryptographic material embedded in thread names, query strings, or system properties.

JEP 536 introduces in-process data redaction directly into the JFR engine:

# Launch application with a configured JFR redaction policy
java -XX:StartFlightRecording=filename=recording.jfr,redact=sensitive-data.xml -jar app.jar

Key Capabilities

• Pattern-Based Masking: Automatically detects credit card numbers, authorization headers, environment secrets, and user credentials.
• In-Memory Sanitization: Redaction occurs before flight recording buffers flush to disk or remote streaming endpoints, ensuring unredacted secrets never persist to disk.
• Custom XML/Regex Profiles: Security teams can supply global enterprise redaction profiles across clusters to guarantee compliance with HIPAA, GDPR, and PCI-DSS.

3. Language & Pattern Matching Refinements

JEP 532: Primitive Types in Patterns, instanceof, and switch (5th Preview)

Project Amber takes another step toward harmonizing primitive and reference types. In Java 27, primitive patterns allow direct inspection, conversion, and validation within switch expressions and instanceof:

public String describeData(Object obj) {
    return switch (obj) {
        // Matches exact primitive or wrapped numeric values
        case byte b               -> "Byte: " + b;
        case short s              -> "Short: " + s;
        case int i when i >= 0    -> "Positive integer: " + i;
        case int i                -> "Negative integer: " + i;
        case long l               -> "Long: " + l;
        case float f              -> "Float: " + f;
        case double d             -> "Double: " + d;
        case boolean bool         -> "Flag: " + bool;
        case null, default        -> "Other / Null: " + obj;
    };
}

Fifth Preview Enhancements:

• Tighter Dominance Rules: The compiler provides stricter checks against unreachable patterns when primitive conversion branches overlap.
• Lossless Unconditional Exactness: Refined casting mechanics prevent silent truncation when widening or narrowing primitive types during pattern binding.

JEP 531: Lazy Constants (3rd Preview)

Formerly explored under Project Leyden as Stable Values, Lazy Constants offer a high-performance alternative to traditional double-checked locking, AtomicReference, and cumbersome memoization utilities:

import java.lang.LazyConstant;

public class ConfigurationProvider {
    // Thread-safe deferred initialization with compile-time final field performance
    private static final LazyConstant<ServerConfig> CONFIG = 
            LazyConstant.of(() -> loadConfigFromRemoteVault());

    public static ServerConfig get() {
        return CONFIG.get();
    }

    private static ServerConfig loadConfigFromRemoteVault() {
        return new ServerConfig("us-east-1.vault.internal", 8443);
    }
}

In its third preview, JEP 531 adds:

• Collection Integration: Support for lazily evaluated arrays and maps where individual elements or keys are computed only when queried, while preserving JIT constant-folding invariants once resolved.
• Diagnostic Inspectability: Built-in methods to verify initialization state without triggering computation (CONFIG.isComputed()).

4. Concurrency, Cryptography & SIMD Vectorization

JEP 533: Structured Concurrency (7th Preview)

Structured Concurrency under Project Loom eliminates thread leaks and orphaned subtasks by coordinating concurrent operations within clear lexical scopes.

import java.util.concurrent.StructuredTaskScope;

public OrderSummary processOrder(String orderId) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        StructuredTaskScope.Subtask<InventoryStatus> invTask = 
                scope.fork(() -> inventoryClient.checkStock(orderId));
        StructuredTaskScope.Subtask<PaymentConfirmation> payTask = 
                scope.fork(() -> paymentClient.authorize(orderId));

        // Wait for all subtasks to complete or any to fail
        scope.join();
        scope.throwIfFailed();

        // Safe consumption of guaranteed completed subtasks
        return new OrderSummary(invTask.get(), payTask.get());
    }
}

Seventh Preview Refinements:

• Enhanced observability integrations with JFR thread-dump events, explicitly visualizing parent-child subtask hierarchies.
• Streamlined Joiner contract for fine-grained timeout fallbacks and partial result collection.

JEP 538: PEM Encodings of Cryptographic Objects (3rd Preview)

Eliminating the historical need to pull third-party dependencies like BouncyCastle for basic certificate handling, JEP 538 introduces native APIs to read and write standard PEM formats:

import java.security.PEMDecoder;
import java.security.PublicKey;

public class CertificateReader {
    public static PublicKey decodeKey(String pemString) throws Exception {
        PEMDecoder decoder = PEMDecoder.of();
        return decoder.decode(pemString, PublicKey.class);
    }
}

Preview 3 adds support for encrypted PEM structures using password callbacks directly compatible with modern password hashing and key derivation algorithms (PKCS#5 and PKCS#8).

JEP 537: Vector API (12th Incubator)

The Vector API enables developers to write architecture-agnostic SIMD code that compiles to AVX-512, Intel AMX, or ARM Neon/SVE vector instructions:

import jdk.incubator.vector.FloatVector;
import jdk.incubator.vector.VectorSpecies;

public class MathEngine {
    private static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;

    public void vectorScalarMultiply(float[] array, float scalar) {
        int i = 0;
        int bound = SPECIES.loopBound(array.length);
        for (; i < bound; i += SPECIES.length()) {
            var v = FloatVector.fromArray(SPECIES, array, i);
            v.mul(scalar).intoArray(array, i);
        }
        // Scalar cleanup for remaining elements
        for (; i < array.length; i++) {
            array[i] *= scalar;
        }
    }
}

The Vector API remains an incubating API awaiting the finalization of Project Valhalla’s Value Objects, which will allow vector elements to be represented as flat, unboxed objects on the stack.

Summary of Benefits & Upgrade Strategy

How to Upgrade to JDK 27

1. Verify Header Compatibility: Run test suites with -XX:+UseCompactObjectHeaders (default in 27) to verify that any third-party reflection, Unsafe, or JNI libraries continue operating smoothly.
2. Review Default GC Settings: If you previously relied on implicit Serial GC behavior on single-CPU micro-containers, verify memory budgets under G1 or specify -XX:+UseSerialGC where needed.
3. Audit TLS Configurations: Ensure intermediate enterprise proxies support post-quantum key exchange groups in TLS 1.3 handshakes.