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.
JDK 27 Early-Access Release Notes
Notable Features
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)
TYPE_USE annotation on var lambda parameter should be rejected (JDK-8371683)
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)
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)
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)
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)
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)
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)
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)
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.