Java 27 and JDK 27 are generally available: what to test before upgrading

Java 27 is available, but it is not an automatic production upgrade

OpenJDK says JDK 27 reached general availability on 15 September 2026. The release is the reference implementation of Java SE 27, the platform specification defined through JSR 402. In everyday use, Java 27 names the platform release and JDK 27 names a development kit that implements it. The distinction matters when a team is choosing a distribution: the OpenJDK project lists production-ready GPL builds, while packaging, patch cadence and paid support are decisions made by individual vendors.

The release carries nine JDK Enhancement Proposals, or JEPs. Several are practical runtime changes that can affect an unchanged application: hybrid post-quantum key exchange for TLS 1.3, G1 as the automatic garbage-collector choice in every environment, compact object headers by default, and in-process redaction in JDK Flight Recorder. Others deliberately remain provisional. An upgrade plan should treat those as two separate questions: whether the stable runtime changes behave well with the service, and whether any new preview or incubator API belongs in application code.

This is a six-month feature release, not a promise of long-term maintenance from every supplier. Oracle says it plans updates for Oracle JDK 27 until March 2027, when Oracle JDK 28 supersedes it. That timing makes Java 27 a reasonable target for teams that can keep pace with the release train or need a delivered feature now. A team whose operational policy favours longer vendor support should compare its selected distribution's Java 25 and Java 27 offerings before making Java 27 the baseline.

JEP 527 changes the TLS 1.3 handshake, not every cryptographic path

The security headline is JEP 527, Post-Quantum Hybrid Key Exchange for TLS 1.3. It adds three hybrid named groups that combine a traditional ephemeral elliptic-curve Diffie-Hellman exchange with ML-KEM: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. The design is intended to address the risk that encrypted traffic collected today could be decrypted later if sufficiently capable quantum computers become available. A hybrid scheme retains a conventional component while adding the post-quantum component, rather than replacing one with the other.

For applications using the JDK's javax.net.ssl APIs, a TLS 1.3 client normally benefits without changing source code. Java 27 puts X25519MLKEM768 first in its default named-group list and offers both X25519MLKEM768 and x25519 key shares. The other two hybrid groups are implemented but are not enabled by default. An application that has explicitly selected named groups, imposed a security policy, used a provider-specific TLS stack or pinned older protocol settings may not receive the default behaviour. Those are configuration questions to inspect, not defects to assume.

The scope needs equally careful wording. JEP 527 applies to TLS 1.3 through javax.net.ssl and does not guarantee peer interoperability or universal post-quantum protection. A peer may not support the hybrid group; normal TLS negotiation can select another mutually supported group. JEP 527 is not an implementation for TLS 1.2, non-TLS protocols or APIs outside javax.net.ssl, and it does not solve certificate management, endpoint compromise or application-level authorization. Test real client, proxy, load-balancer and upstream-server combinations before describing a traffic path as post-quantum protected.

How to test hybrid TLS before relying on the new default

Begin with an inventory of outbound and inbound TLS paths. Record each Java runtime, the protocol versions that are actually negotiated, any jdk.tls.namedGroups property, code that calls SSLParameters.setNamedGroups, and the terminating peer. That peer could be a browser-facing proxy, an API gateway, a database driver, a service mesh sidecar or a partner endpoint. It is not enough to confirm that the application starts on JDK 27, because the change takes effect during a TLS 1.3 handshake and the peer decides whether a preferred group can be used.

A useful staging test exercises the same certificate chain, cipher policy, middleboxes and connection-reuse pattern as production. Capture the negotiated protocol and named group using approved observability at the client or server, then test the fallback path with a peer that does not support the hybrid group. Watch for handshake failures, unexpected latency, incompatibility in TLS inspection equipment and a material change in connection establishment. Do not treat a generic JDK unit test as independent proof for a particular network path; OpenJDK's testing plan includes interoperability testing, while a deployment's proxies and policies remain its own responsibility.

If an operator must set jdk.tls.namedGroups or call SSLParameters.setNamedGroups, preserve conventional groups in the approved configuration unless the full peer set has been validated. The new default preference is useful precisely because it allows compatibility negotiation. Replacing it with an overly narrow list can turn a security migration into an availability incident.

G1 becomes the automatic choice in every HotSpot environment

JEP 523 makes the Garbage-First collector, usually called G1, the default whenever HotSpot starts without an explicit garbage-collector selection. Earlier JDKs could choose the Serial collector in constrained conditions, such as limited memory or processor capacity. Java 27 removes that automatic split: G1 is selected in server and non-server environments alike. It does not remove Serial, Parallel, ZGC or another existing collector, and it does not override a command-line selection.

That simplification improves predictability, but it should not be recast as an across-the-board performance claim. The JEP's goal is that throughput, latency, memory footprint and startup time should not degrade significantly in situations where the JVM previously chose Serial. Its risk section also says some constrained applications may still run best with Serial, which can still be selected explicitly. A small container, desktop utility or single-core workload is therefore a test case, not a reason to assume that defaults will match its previous behaviour.

Check launch scripts, container base images and platform charts for inherited -XX:+Use...GC flags before testing. A service with an explicit setting will not be evaluating the new default at all. For services that intentionally rely on default selection, compare warmed throughput, tail latency, startup, RSS, heap commitment and garbage-collection logs under representative limits. Java 27 also changes G1's default MinHeapFreeRatio and MaxHeapFreeRatio values to 0 and 100; explicit values retain their existing specified behaviour.

Compact object headers can save heap, but measurement still decides

JEP 534 switches compact object headers on by default in the HotSpot JVM on 64-bit architectures. The layout reduces a typical object header from 96 bits to 64 bits. That can reduce heap footprint, improve data locality and, in some workloads, reduce garbage-collection pressure. It is a runtime-layout default rather than a new Java language construct, so an unchanged object-heavy application may see a different memory profile after the upgrade.

The evidence supporting the default is encouraging but not a blanket benchmark promise. The JEP cites testing by Oracle, Amazon and SAP, and reports results from particular experiments, including a SPECjbb2015 setting. Those results do not establish a percentage reduction for an organisation's cache-heavy application, ORM model, serialization workload or native-library integration. Heap occupancy, allocation rate, CPU, pause distribution and startup should be measured in the deployment shape that matters, not inferred from a JEP example.

The prior layout has not been removed. If diagnosis requires comparison, Java 27 can start with -XX:-UseCompactObjectHeaders; the release notes say that opt-out is planned for deprecation and eventual removal. Test software that relies on agents, native code, heap tooling or unusual object-layout assumptions early. A failure is not implied by the feature, but this is the part of the migration where an integration test is more informative than a synthetic memory number.

JFR redaction improves diagnostics handling, with a defined boundary

JEP 536 adds in-process data redaction to JDK Flight Recorder, or JFR. By default, it redacts many sensitive-looking command-line arguments and the initial values of environment variables and system properties before the relevant data leaves the Java process. That matters because recordings can otherwise carry access tokens, passwords and other configuration secrets into files, support cases or central analysis systems. It is a practical reduction in one diagnostic-data exposure path, not evidence that all recordings are safe to distribute without review.

The filters use case-insensitive glob-style matching. Java 27 supplies default patterns for terms such as password, secret, token and private key, while operators can add filters or load them from a file. Redaction changes what a recording contains, so support teams should validate that the fields still useful for troubleshooting remain visible and that organisation-specific secret names are covered. The feature can be disabled, but doing so restores the older risk of placing sensitive startup data in JFR output.

This change is particularly relevant when Java services support model or automation workloads that have external tools and credentials. Runtime redaction does not replace least-privilege configuration, secret rotation or review of a managed platform's data rules.

Preview and incubator features are available, not settled contracts

Four Java 27 features are previews: Lazy Constants in its third preview; primitive types in patterns, instanceof and switch in its fifth; Structured Concurrency in its seventh; and PEM encodings of cryptographic objects in its third. The Vector API is in its twelfth incubation. Preview features are specified and implemented, but deliberately impermanent; incubator modules similarly exist to collect feedback before their APIs become final. Neither label means that a feature is missing from the GA build. It means the interface or language design may still change or disappear in a later release.

That is an operational constraint, not merely a compiler detail. Normal preview APIs and language features are disabled by default. Code that uses them must opt in at compilation and again at run time, typically with javac --release 27 --enable-preview and java --enable-preview. Preview-dependent class files are tied to that release and should not be distributed beyond the control of the team that made the choice. The PEM API, for example, offers encode/decode support for keys, certificates and certificate-revocation lists, but is still a preview API in Java 27.

Structured Concurrency and primitive patterns may be attractive for a new service, while Vector API use may be relevant to compute-intensive code. A conservative upgrade can run existing production code on Java 27 without adopting any of them. A deliberate adoption should isolate the dependency, add build and runtime flags in every environment, pin the toolchain and plan a revalidation at Java 28. That separation prevents a routine JDK upgrade from silently becoming a long-term dependency on an evolving API.

A production upgrade sequence that finds the changes that matter

First, establish the baseline. Record the installed vendor distribution, full java --version output, architecture, OS image, JVM options, garbage collector, TLS configuration, Java agents and native dependencies. Build and test the application with the same dependency-resolution rules used in production. JDK 27 also removes the experimental JVM Compiler Interface and its related modules and flags, and removes several obsolete verification options including -Xverify:none. A startup failure or a dependency on an internal module is a compatibility item to fix, not something a new runtime default will conceal.

Next, promote through an environment that preserves production constraints. Run functional and integration tests, then soak the service under representative traffic. Compare handshake success and TLS group negotiation, allocation and GC behaviour, heap use, p95 and p99 latency, CPU, startup, JFR output and operational dashboards. Test client libraries and external endpoints as well as the service's own server port. For compact headers, test instrumentation and native integrations; for JFR, inspect a generated recording to verify the redaction outcome; for G1, ensure the observed collector is the one the test intends to assess.

Finally, decide feature by feature. A team may adopt Java 27 for the stable defaults yet defer preview APIs. It may validate hybrid TLS on internal paths while waiting for a partner endpoint to support the preferred group. It may retain an explicit collector in one constrained deployment while accepting G1 elsewhere. That is not a partial upgrade; it is an evidence-based use of a release whose changes span security, memory management and developer APIs.

The practical decision: adopt for the tested benefits, not a label

Java 27 offers useful improvements even to code that does not change: a modernised TLS 1.3 preference, one predictable default collector, smaller object headers on supported HotSpot configurations and safer-by-default handling of several JFR fields. Those are strong reasons to put the release in a compatibility pipeline. They are not reasons to claim a fixed performance gain, universal post-quantum coverage or a completed cryptographic migration.

For most teams, the balanced route is clear. Download a GA build from the chosen vendor, confirm its full version and support policy, test the stable runtime defaults against the real estate of peers and deployment limits, and keep preview and incubator experiments explicitly bounded. Recheck vendor release notes before a broad rollout because operational details can change in update releases. Java 27 is a capable feature release; whether it is the right production baseline depends on the measured result and the support timetable your organisation actually has.