JDK 27 Early-Access Release Notes

Latest Update: 2026-02-27
This is a draft of the release notes that will accompany 27. The contents are subject to change until release.

Notable Features

527: Post-Quantum Hybrid Key Exchange for TLS 1.3

Enhance the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms for TLS 1.3. Such algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm. Applications that use the javax.net.ssl APIs will benefit from these improved algorithms by default, without change to existing code.

Build 11

NPE for empty TreeMap/TreeSet sub-set Spliterator and Stream (JDK-8376698)

core-libs/java.util:collections

Empty subsets of TreeMap and TreeSet now throw NullPointerException when passing a null action to Stream.forEach, Spliterator.forEachRemaining or Spliterator.tryAdvance. In prior releases, implementations of Spliterator and Stream for subsets of TreeMap and TreeSet returned false or completed normally when passed a null action if the subset was empty, instead of throwing NullPointerException as required by the specification.

TYPE_USE annotation on var lambda parameter should be rejected (JDK-8371683)

tools/javac

Type annotations, i.e. annotations that are not applicable for local variables and parameter declarations, and have @Target(TYPE_USE), will now be consistently rejected for all variables with inferred types (i.e. using var). This includes lambda parameters and for-each variables.

Behavior Change of HttpServer from String Prefix Matching to Path Prefix Matching (JDK-8272758)

core-libs/java.net

The behavior of the JDK built-in com.sun.net.httpserver.HttpServer implementation, when matching an incoming request path to an HttpContext path, is switched from string prefix matching to path prefix matching. This means the request path must begin with the context path and all matching path segments must be identical. For instance, the context path /foo would match request paths /foo, /foo/, and /foo/bar, but not /foobar. The old behavior, string prefix matching, can be enabled using the newly introduced sun.net.httpserver.pathMatcher (link not found) system property. This property and the ability to restore the old behavior may be removed in a future release.

Build 10

Enforcement Of Valid javax.net.debug Option Combinations In TLS (JDK-8044609)

security-libs/javax.net.ssl

The parsing of the javax.net.debug system property for TLS/SSL debug logging has been updated to strictly enforce documented option and sub-option relationships. Sub-options such as verbose, packet, and plaintext now require their respective parent options, and only valid combinations have an effect. Invalid or unsupported combinations are silently ignored.

Previously, some sub-options could be used independently or in incorrect combinations, contrary to the intended design. The help message (-Djavax.net.debug=help) has also been updated to accurately reflect all supported and obsolete entries.

Users who previously relied on undocumented or invalid combinations (for example, specifying only -Djavax.net.debug=verbose) will need to update their configurations to match the documented usage. Please refer to the updated help output for the current list of valid options and examples of correct usage.

Build 9

TimeZone.getDefault() Returns Obsolete ID on Windows (Asia/Calcutta) (JDK-8377013)

core-libs/java.util:i18n

The default time zone returned by TimeZone.getDefault() on Windows now reflects the latest IANA TZ database IDs, aligning with current IANA definitions. Previously, for some regions, such as India, the method returned obsolete IDs (e.g., "Asia/Calcutta"), but it now correctly returns the current IDs (e.g., "Asia/Kolkata")

Build 8

Predefined ISO-8601 Formatters Support Short Zone Offsets (JDK-8210336)

core-libs/java.time

Predefined ISO-8601 based formatters in the DateTimeFormatter class that accept zone offsets (for example, ISO_DATE) now support short zone offsets for parsing. In previous releases, parsing offsets without seconds or nanoseconds (for example, +01) resulted in a DateTimeParseException with some ISO formatters. These offsets are now parsed successfully by all predefined ISO formatters that accept zone offsets.

Build 6

Post-Quantum Hybrid Key Exchange for TLS 1.3 (JDK-8314323)

security-libs/javax.net.ssl

Enhance the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms for TLS 1.3. Such algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm. Applications that use the javax.net.ssl APIs will benefit from these improved algorithms by default, without changes to existing code.

The following three new hybrid key exchange algorithms are supported: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. Only the X25519MLKEM768 hybrid key exchange algorithm is placed at the front of the default named groups list, making it the most preferred group.

For more details, see JEP 527.

Build 2

Removal of ThreadPoolExecutor.finalize() (JDK-8371748)

core-libs/java.util.concurrent

The finalize() method has been removed from java.util.concurrent.ThreadPoolExecutor.

ThreadPoolExecutor.finalize() was deprecated in JDK 9 as part of deprecating finalization for removal JEP 421. The method was re-specified in JDK 11 to "do nothing" and deprecated for removal in JDK 18.

The removal of this method means that any existing code that extends ThreadPoolExecutor and overrides finalize() to call super.finalize() (or calls finalize() directly) will now call Object.finalize(). This code may no longer compile as Object.finalize() throws Throwable whereas the removed ThreadPoolExecutor.finalize() did not declare any checked exceptions. Developers are strongly encouraged to stop using finalization but if necessary, the source compatibility issue can be worked around using a try-catch.

Removal of the java.locale.useOldISOCodes System Property (JDK-8355522)

core-libs/java.util:i18n

Support for the java.locale.useOldISOCodes system property in the java.util.Locale class has been removed. Originally introduced in JDK 17, this property allowed applications to revert to legacy ISO 639 language codes ("iw" for Hebrew, "ji" for Yiddish, and "in" for Indonesian). It was deprecated in JDK 25 and, starting with JDK 27, specifying this property has no effect and triggers a warning at runtime. Users who still rely on the old codes are encouraged to transition to the current standard codes: "he" for Hebrew, "yi" for Yiddish, and "id" for Indonesian.