public class PrimitivePatternDemo {
    static String classify(Object value) {
        return switch (value) {
            case int i when i < 0 -> "negative int: " + i;
            case int i -> "non-negative int: " + i;
            case double d -> "a double: " + d;
            default -> "something else";
        };
    }

    public static void main(String[] args) {
        System.out.println(classify(-5));
        System.out.println(classify(42));
        System.out.println(classify(3.14));
        System.out.println(classify("hello"));
    }
}

negative int: -5
non-negative int: 42
a double: 3.14
something else

import java.util.concurrent.StructuredTaskScope;

public class StructuredConcurrencyDemo {

    record InventoryInfo(int unitsLeft) {}
    record PricingInfo(double price) {}

    static InventoryInfo fetchInventory() throws InterruptedException {
        Thread.sleep(80);
        return new InventoryInfo(24);
    }

    static PricingInfo fetchPricing() throws InterruptedException {
        Thread.sleep(120);
        return new PricingInfo(49.99);
    }

    public static void main(String[] args) throws Exception {
        try (var scope = StructuredTaskScope.open()) {
            var inventoryTask = scope.fork(StructuredConcurrencyDemo::fetchInventory);
            var pricingTask = scope.fork(StructuredConcurrencyDemo::fetchPricing);

            scope.join();

            System.out.println("Inventory: " + inventoryTask.get());
            System.out.println("Pricing: " + pricingTask.get());
        }
    }
}

Output:

Inventory: InventoryInfo[unitsLeft=24]
Pricing: PricingInfo[price=49.99]

JEP 534: Compact Object Headers by Default

Every object on the 64-bit HotSpot JVM has carried a 96-bit (12-byte) header since forever: a mark word plus a class pointer. Project Lilliput has been chipping away at that for several releases: experimental in Java 24 (JEP 450), opt-in and production-ready in Java 25 (JEP 519), and now, with JEP 534, switched on by default in Java 27.

java -XX:+PrintFlagsFinal -version | grep -i CompactObjectHeaders

bool UseCompactObjectHeaders = true {product lp64_product} {default}

Reported gains from Oracle’s own SPECjbb2015 benchmarking: roughly 22% less heap space and 8% less CPU time, with about 15% fewer garbage collection cycles, simply from smaller headers packing more live objects per region. If you need the old 96-bit layout for compatibility reasons, you can still disable it:

java -XX:-UseCompactObjectHeaders -jar your-application.jar

There is no application code to change here. It is exactly the kind of feature that helps you without you noticing, until you check your container’s memory graphs after the upgrade.

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

This is arguably the headline feature of Java 27. TLS 1.3 connections that rely only on classical key exchange algorithms are vulnerable to a “harvest now, decrypt later” attack: an adversary records encrypted traffic today and waits for a sufficiently powerful quantum computer to decrypt it later. JEP 527 adds three hybrid key exchange schemes to the SunJSSE provider, each combining a quantum-resistant ML-KEM algorithm with a traditional elliptic-curve algorithm, so the connection stays secure as long as at least one of the two algorithms remains unbroken.

import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLParameters;
import javax.net.ssl.SSLSocket;
import java.util.Arrays;

public class PostQuantumTlsDemo {
    public static void main(String[] args) throws Exception {
        SSLSocket socket = (SSLSocket) SSLContext.getDefault()
                .getSocketFactory()
                .createSocket();

        SSLParameters params = socket.getSSLParameters();
        System.out.println("Default named groups: " + Arrays.toString(params.getNamedGroups()));

        // Explicitly prefer two hybrid post-quantum groups, then fall back to classical ones
        params.setNamedGroups(new String[] {
                "SecP256r1MLKEM768", "X25519MLKEM768", "secp256r1", "x25519"
        });
        socket.setSSLParameters(params);
    }
}

Illustrative output:

Default named groups: [X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096]

Notice that X25519MLKEM768, the hybrid scheme, is already first in the default list. Applications using the standard javax.net.ssl API get this protection automatically, with zero code changes, as long as they have not already hard-coded a specific set of named groups. You can also control the default list JVM-wide with the jdk.tls.namedGroups system property instead of touching code.

JEP 536: JFR In-Process Data Redaction

Java Flight Recorder is a favorite tool for diagnosing production issues, but recordings capture command-line arguments, environment variables, and system properties verbatim, including any passwords, API keys, or tokens that happen to be passed that way. Once a .jfr file is shared with a support team or attached to a bug report, that secret is out. JEP 536 redacts this data in-process, before it is ever written to the recording.

# Start a recording on a service launched with a password on the command line
java -XX:StartFlightRecording:filename=recording.jfr -jar payment-service.jar --password=Sup3rSecret

# The default filters redact it automatically before anything hits recording.jfr
jfr print --events InitialSystemProperty,JVMInformation recording.jfr

jdk.JVMInformation {
  javaArguments = "-jar payment-service.jar [REDACTED]"
}

You can extend the default filters with your own application-specific keywords, or load them from a file to avoid unwieldy command lines:

java -XX:FlightRecorderOptions:'redact-key=+confidential;secret;@keys.txt' -jar app.jar

And if you genuinely need the old, unredacted behavior for a specific diagnostic session:

java -XX:FlightRecorderOptions:'redact-key=none,redact-argument=none' -jar app.jar

The PEMEncoder/PEMDecoder API you may have used in Java 26 (JEP 524) goes through a third preview round here. Interestingly, this JEP was originally expected to finalize in Java 27 after two preview rounds, but late feedback from the community led the team to ship one more preview instead, a reminder that “third preview” does not always mean “smooth, incremental polish”; sometimes it means real design questions surfaced late.

import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PEMEncoder;
import java.security.PEMDecoder;
import java.security.PrivateKey;

public class PemEncodingDemo {
    public static void main(String[] args) throws Exception {
        KeyPairGenerator generator = KeyPairGenerator.getInstance("EC");
        KeyPair keyPair = generator.generateKeyPair();

        String pemText = PEMEncoder.of().encodeToString(keyPair.getPrivate());
        System.out.println(pemText);

        PrivateKey decodedKey = PEMDecoder.of().decode(pemText, PrivateKey.class);
        System.out.println("Decoded key algorithm: " + decodedKey.getAlgorithm());
    }
}

-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQg...
-----END PRIVATE KEY-----
Decoded key algorithm: EC

If your team is still on Java 26 and used PEMEncoder/PEMDecoder there, this code keeps working unchanged; the third preview mostly refines edge cases rather than the everyday encode/decode path shown above.

JEP 537: Vector API (Twelfth Incubator)

The Vector API reaches its twelfth incubation round, with no substantial implementation changes since Java 25. It still lives in the jdk.incubator.vector module, expressing SIMD-style vector computations that the JIT compiles down to native vector instructions where the CPU supports them.

import jdk.incubator.vector.DoubleVector;
import jdk.incubator.vector.VectorSpecies;

public class VectorApiDemo {
    static final VectorSpecies<Double> SPECIES = DoubleVector.SPECIES_256;

    public static void main(String[] args) {
        double[] prices = {19.99, 29.99, 9.99, 49.99};
        double[] discounted = new double[prices.length];

        DoubleVector priceVector = DoubleVector.fromArray(SPECIES, prices, 0);
        priceVector.mul(0.9).intoArray(discounted, 0);

        System.out.println(java.util.Arrays.toString(discounted));
    }
}

Output:

[17.991, 26.991, 8.991, 44.991]

Compile and run it with the incubator module explicitly on the module path:

javac --add-modules jdk.incubator.vector VectorApiDemo.java 
java --add-modules jdk.incubator.vector VectorApiDemo

How Do You Enable Preview Features in Java 27?

Four JEPs here (531, 532, 533, 538) are previews, and one (537) is an incubator module. Both categories need explicit flags on the command line:

As always, avoid building production code paths around preview APIs. The removal of isInitialized()/orElse() from Lazy Constants between Java 26 and Java 27 is a good live example of exactly why: preview APIs can and do change shape between releases.

Common Mistakes to Avoid

• Assuming Compact Object Headers or the G1-everywhere change need a flag to take effect. Both are on by default in Java 27; you would need a flag to turn them off, not on.
• Skipping a staging measurement after a “routine” base image bump to jdk:27. Two default JVM behaviors changed (GC selection and object header size), even though no application code did.
• Hard-coding a specific list of TLS named groups and then wondering why post-quantum key exchange never kicks in. JEP 527 only helps automatically if your code has not already overridden the default group list.
• Treating JEP 538’s “third preview” as a formality. It exists specifically because the API was not ready to finalize, so expect at least one more preview round before PEM encoding is locked in.
• Forgetting –enable-preview on both javac and java for JEP 531, 532, 533, and 538 code.

Frequently Asked Questions (FAQs)

Q#1: Is Java 27 a long-term support (LTS) release?

No. Java 27 is a short-term, non-LTS release supported for six months. Java 25 remains the current LTS version, and the next LTS is expected to be Java 29 around September 2027.

Q#2: What are the biggest new features in Java 27?

The four finalized JEPs stand out: G1 as the default garbage collector in all environments (JEP 523), Compact Object Headers on by default (JEP 534), post-quantum hybrid TLS 1.3 key exchange (JEP 527), and JFR in-process data redaction (JEP 536).

Q#3: Do I need to change my code to get post-quantum TLS protection?

No. As long as your application uses the standard javax.net.ssl APIs and does not explicitly override the TLS named groups, the hybrid X25519MLKEM768 scheme is preferred automatically.

Q#4: Why did the PEM encoding API (JEP 538) get a third preview instead of finalizing?

It was originally planned to finalize in Java 27 after two preview rounds, but late community feedback led the OpenJDK team to ship one more preview round to address open design questions first.

Q#5: How do I enable preview features in Java 27?

Compile with javac –release 27 –enable-preview Main.java and run with java –enable-preview Main, or use the single-file source launcher directly with java –enable-preview Main.java.

Q#6: What changed in Structured Concurrency’s seventh preview?

StructuredTaskScope and Joiner gained a third type parameter that describes exactly which exception type join() can throw, giving callers more precise, compile-time-checked error handling.

Conclusion: Should You Upgrade to Java 27?

Java 27 is a smaller release than Java 26 in JEP count, but two of its finalized changes, Compact Object Headers and G1 everywhere, are exactly the kind of “free” improvements worth grabbing in any environment where you can move off Java 25 or 26 without an LTS commitment. JEP 527’s post-quantum TLS support is the standout for security-conscious teams, especially anyone with a compliance deadline around quantum readiness. Everything still in preview (Lazy Constants, primitive patterns, Structured Concurrency, PEM encoding) or incubation (the Vector API) is worth tracking now, since most of it is expected to stabilize by the time Java 29 arrives as the next LTS.

If you want to try these examples without setting up a local JDK 27 environment, use our free online Java compiler and code runner.

References:

• https://openjdk.org/projects/jdk/27/
• https://openjdk.org/jeps/523
• https://openjdk.org/jeps/527
• https://jdk.java.net/27/release-notes

For other version’s features, kindly go through Java Features After Java 8.