RELEASE NOTES: JDK 28

The Java Compiler Now Performs Exception and Reachability Analyses on Switch Guards

javac now - rejects source code when a switch guard throws a checked exception that is neither caught nor declared - rejects source code when a switch guard contains a statement that is unreachable.

Changed `HttpCookie` to Accept Cookies With Invalid `Expires` Attribute As Session Cookies

java.net.HttpCookie will ignore the value of the Expires attribute of a cookie, if the attribute value cannot be parsed into a valid date. Such cookies do not expire till the end of the session. This new behaviour matches the Expires attribute specification of RFC-6265.

Previously, the failure to parse the value of the Expires attribute would have resulted in the cookie being discarded.

Specification of `sun.net.httpserver.maxReqTime` and `sun.net.httpserver.maxRspTime` System Properties Corrected to State Their Values are in Seconds

The specification of the sun.net.httpserver.maxReqTime and sun.net.httpserver.maxRspTime system properties, which are used to configure the HTTP server in the jdk.httpserver module, has been corrected to state that their values are in seconds. This change updates the specification to match the long standing behaviour in the implementation.

java.sql.Date and java.sql.Timestamp Preserve BC Years in java.time Conversions

The [java.sql.Date.toLocalDate()] and [java.sql.Timestamp.toLocalDateTime()] conversions now preserve BC years correctly. Previously, if the underlying SQL date or timestamp contained a BC year, these conversions would incorrectly return a result containing an AD year. For example, a java.sql.Date representing January 1, 2 BC would be converted to a java.time.LocalDate of 0002-01-01. After this change, that same value is now correctly converted to -0001-01-01.

Applications that convert BC java.sql.Date or java.sql.Timestamp values will now observe the corrected year in the resulting java.time value. Conversions of AD values will remain unchanged.

CachedRowSet Warns Once On Max Rows

The JDK implementation for [javax.sql.CachedRowSet.populate(ResultSet)] now reports at most a single warning when the maximum rows (configured with [javax.sql.RowSet.setMaxRows(int)]) is exceeded. Previously, a new warning was chained for each additional row past the maximum. The behavior of [javax.sql.CachedRowSet.populate(ResultSet, int)] remains unchanged, as it correctly reported a single warning.

The JDK implementation for [javax.sql.CachedRowSet.getRowSetWarnings()] has been updated so that the root warning contains a message. Previously, the root warning returned by this method had an empty message. Additionally, the method now correctly returns null when there are no warnings present in the CachedRowSet.

java -XshowSettings Exits Normally When Used Without a Java Application

The java -XshowSettings option now exits with status 0 when used without a Java application. After displaying the requested settings, the launcher no longer prints the general usage information.

Allow configuration of the JVM's temporary directory on Linux

An advanced serviceability option has been added to the JVM to allow configuration of an alternate temporary directory on Linux.

-XX:AltTempDir=/path

On Linux, the usual directory to use for temporary files is /tmp. In some secure container environments however, /tmp is made read-only and so is unusable by the VM for its temporary files. To accommodate this uncommon circumstance the -XX:AltTempDir flag can be used to tell the VM to use a different temporary directory.

See the java man page under ADVANCED SERVICEABILITY OPTIONS FOR JAVA for more details.

cacerts jlink plugin

A new jlink plugin has been added which allows the user to specify the specific CA (Certificate Authority) certificates to include in the cacerts keystore in a custom runtime image. This is very useful for creating runtimes that only contain the CA certificates that are needed by applications which will be using that custom runtime. The command-line syntax takes one or more cacerts keystore aliases as an option, separated by a comma.

For example:

jlink --cacerts "letsencryptisrgx1 [jdk]"

or

jlink --cacerts "letsencryptisrgx1 [jdk],digicertglobalrootca [jdk]"

Default PKCS12 Mac Algorithm Is Now PBMAC1

The default value of the keystore.pkcs12.macAlgorithm security property is now PBEWithHmacSHA256. Newly created PKCS #12 keystores use PBMAC1 integrity protection, a more modern and extensible mechanism.

LuxTrust Global Root CA removed

The following root certificate has been removed from the cacerts keystore: ``` + alias name "luxtrustglobalrootca [jdk]" Distinguished Name: CN=LuxTrust Global Root, O=LuxTrust s.a., C=LU

```

ListFormat Single Quote Handling Fixed

The JDK reference implementation for [java.text.ListFormat] is no longer affected by [java.text.MessageFormat] single quote escaping semantics. For example, previously, a list pattern such as " '{0}', {1} " may have incorrectly formatted List.of("bar", "foo") as: " {0}, bar ". ListFormat is now updated to always treat single quotes as literal characters when read from a pattern.

This change is observable for ListFormat patterns that contain single quotes. As a result, it primarily affects application-supplied custom patterns that contain them.

Custom ListFormat Patterns Are Validated More Strictly

[java.text.ListFormat.getInstance(String[])] now validates custom list format patterns more strictly. Only the exact placeholders "{0}", "{1}", and "{2}" are accepted, and "{2}" is accepted only in the three-element pattern. Patterns with duplicate placeholders or curly braces outside valid placeholders now cause an [IllegalArgumentException] to be thrown.

This change affects only application-supplied custom patterns passed to [ListFormat.getInstance(String[])]. Locale-derived ListFormat instances are not affected.

GZIPInputStream Restores Pre-JDK 23 Read-Ahead Behavior

To determine whether additional GZIP members follow the current member, java.util.zip.GZIPInputStream checks for another member after reading the current member's trailer.

In releases prior to JDK 23, [GZIPInputStream] called InputStream.available() on the underlying stream before attempting to read the next member header. JDK 23 changed this behavior (see JDK-7036144) to skip the available() call and instead attempt the read directly.

Because this change introduced compatibility issues for some applications, GZIPInputStream has been restored to its pre-JDK 23 behavior. It once again calls [InputStream.available()] before attempting to read the next member header.

A new system property, [jdk.util.gzip.tryReadAheadAfterTrailer], has been added. Setting this property to true restores the pre-JDK 23 behavior: GZIPInputStream attempts to read the next member header without first calling InputStream.available(). This property is intended for applications that depend on that behavior.

ML-DSA in TLS 1.3

SunJSSE now supports the TLS 1.3 ML-DSA signature schemes mldsa65, mldsa87, and mldsa44. With this support, TLS 1.3 in the JDK can use ML-DSA end-entity certificates and ML-DSA CertificateVerify signatures for authentication.

These schemes are placed at the front of the SunJSSE default signature scheme preference list in the following order: mldsa65, mldsa87, and mldsa44.

This support applies only to TLS 1.3.

Capture Named Group information in TLSHandshakeEvent

The jdk.TLSHandshakeEvent JFR event now records the named group that is negotiated in a TLS handshake. A new field named namedGroup has been added to the event.

Significant performance gains in X25519 key agreement and Ed25519 signature algorithms

The underlying Curve25519 operations have been provided intrinsics in this release which has resulted in noticeable performance improvements for the X25519 key agreement algorithm and the Ed25519 signature algorithm as follows:

1. x86-64 architecture

2. X25519 Key generation: +19%

3. X25519 Decapsulation: +19%

4. X25519 Encapsulation: +19%

5. Ed25519 Key generation: +20%

6. Ed25519 Signing: +19%

7. Ed25519 Verification: +16%

8. AArch64 architecture

9. X25519 Key generation: +10%

10. X25519 Decapsulation: +9%

11. X25519 Encapsulation: +9%

12. Ed25519 Key generation: +15%

13. Ed25519 Signing: +12%

14. Ed25519 Verification: +12%

Improved ML-DSA Performance

The Java implementation of the ML-DSA signature algorithm has been optimized. Signing and verification are faster on platforms that use the Java implementation. Performance is also improved on platforms with ML-DSA intrinsics enabled.

RSA/ECB/PKCS1Padding Is Now a Legacy Algorithm

The default JDK security configuration now classifies Cipher.RSA/ECB/PKCS1Padding as a legacy algorithm by adding it to the jdk.crypto.legacyAlgorithms security property. The algorithm remains available, but its use will generate a runtime warning indicating that the algorithm is considered legacy and may be disabled in a future release.

Significant performance gains in X25519 key agreement and Ed25519 signature algorithms

The underlying Curve25519 operations have been provided intrinsics in this release which has resulted in noticeable performance improvements for the X25519 key agreement algorithm and the Ed25519 signature algorithm as follows:

1. x86-64 architecture

2. X25519 Key generation: +19%

3. X25519 Decapsulation: +19%

4. X25519 Encapsulation: +19%

5. Ed25519 Key generation: +20%

6. Ed25519 Signing: +19%

7. Ed25519 Verification: +16%

8. AArch64 architecture

9. X25519 Key generation: +10%

10. X25519 Decapsulation: +9%

11. X25519 Encapsulation: +9%

12. Ed25519 Key generation: +15%

13. Ed25519 Signing: +12%

14. Ed25519 Verification: +12%

jlink --strip-debug` now removes external debug symbol files (.debuginfo, .diz, .dSYM, .pdb)

jlink --strip-debug now removes external debug symbol files (.debuginfo, .diz, .dSYM, .pdb)

The jlink --strip-debug option previously only stripped embedded native debug symbols from executables and shared libraries (i.e. debug info stored inside the binary itself). When a JDK was built with --with-native-debug-symbols=external — the default for fastdebug and debug builds — the accompanying .debuginfo and .diz files were silently copied into the resulting image, leaving debug information present despite the intent of --strip-debug.

The option now consistently excludes external debug symbol files (.debuginfo and .diz) from the generated image on Linux, regardless of how the source JDK was built. The behavior for builds using --with-native-debug-symbols=internal is unchanged.