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.

javac Correctly Types Conditional and Switch Expressions Mixing Raw and Parameterized Types

Prior to JDK 28, javac could incorrectly determine the type of a standalone reference conditional or switch expression when its result expressions mixed raw and parameterized types. In some cases, whether the code compiled depended on the order of those expressions. For example, the following code was previously accepted, erroneously, because javac used unchecked assignment conversion and selected List<Integer> as the type of the conditional expression. However, if this code included b ? raw : parameterized (the alternative ordering), it was correctly rejected.:

``` import java.util.List;

class Test { Integer first(boolean b, List raw, List parameterized) { return (b ? parameterized : raw).get(0); } } ```

Starting with JDK 28, javac determines the type of these expressions according to the Java Language Specification. As a result, code that previously compiled only because a parameterized expression appeared before a raw expression may now be rejected. For example, in the previous example, in (b ? parameterized : raw).get(0), the expression has raw type List, so get(0) has type Object and cannot be safely converted to Integer.

Release note: Removal of the `jdk.net.useFastTcpLoopback` System Property

The system property jdk.net.useFastTcpLoopback, to enable the SIO_LOOPBACK_FAST_PATH socket I/O control code on Windows, has been removed. Setting the system property now has no effect. Microsoft documents the SIO_LOOPBACK_FAST_PATH socket I/O control code as deprecated and recommends that it no longer be used.

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.

Removal of `sun.cpu.isalist` System Property

The system property sun.cpu.isalist has been removed.

The system property was originally introduced in JDK 1.3 to report the available CPU instruction sets on Solaris. On other systems the system property was never fully implemented.

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.

Releaste Note: Remove implementations of deprecated MBeanServer method

The JDK-internal com.sun.jmx.mbeanserver.JmxMBeanServer implementations of "deserialize" methods are removed. Any call to these methods will be handled by the default implementation in javax.management.MBeanServer, which unconditionally throws UnsupportedOperationException.

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]"

Entrust G4 Root CA Removed

The following root certificate has been removed from the cacerts keystore: ``` + alias name "entrustrootcag4 [jdk]" Distinguished Name: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

```

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

```

keytool Keypair Generation Defaults are Provider-Independent

keytool now always uses the defaults as listed in [its man page][keytool#defaults-of-option-values] when generating key pairs and does not use provider defaults. Previously, it used the JDK provider's defaults unless the -keysize or -groupname options were specified.

Added Certum Trusted Root CA and Certum EC-384 CA Certificates

The following root certificates have been added to the cacerts truststore: ``` + Certum + certumtrustedrootca DN: CN=Certum Trusted Root CA, OU=Certum Certification Authority, O=Asseco Data Systems S.A., C=PL

• Certum
• certumec384ca DN: Certum EC-384 CA, OU=Certum Certification Authority, O=Asseco Data Systems S.A., C=PL ```

Add JDK Specific Property for External Resource Access

A new JDK specific property, jdk.xml.resource.access, has been added to control access to external resources used by XML processors. The property accepts a list of URI patterns that can restrict access based on URI scheme, host, port, and path, with wildcard support for defined components. The following for example:

jdk.xml.resource.access = https://*.sun.com, http://www.w3.org, file:/dtds/*

allows access to any subdomain of sun.com, resources from w3.org, and resources under the local dtds directory.

The property can be configured in multiple ways, including through API methods, system properties, and the JAXP Configuration File.

The property complements the existing JAXP External Access Properties (EAPs) by providing finer-grained resource access control. By default, all resource access is allowed to preserve compatibility with existing applications. Applications that require restricted resource access should configure the property explicitly rather than rely on the default, as the default may change in a future release.

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.

Add APIs to get supported and negotiated named groups

New methods have been added to the javax.net.ssl API to obtain supported and negotiated key exchange named groups: - [SSLEngine.getSupportedNamedGroups], [SSLSocket.getSupportedNamedGroups], and [SSLServerSocket.getSupportedNamedGroups] return the named groups that the underlying provider could enable for use. - [ExtendedSSLSession.getNamedGroup] returns the named group negotiated for the session, or null if no named group was negotiated or the handshake has not completed. The SunJSSE provider implements these methods. The default implementations throw UnsupportedOperationException if the underlying provider does not implement the operation.

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%

Launching of application in Desktop.browse() is disabled by default

A new implementation System Property (awt.desktop.browse_insecure) is provided to partially re-enable previous behaviour of the java.awt.Desktop.browse() API. This is an opt-in property, and the value is a comma-separated list of URL schemes.

Eg :

-Dawt.desktop.browse_insecure=file,ftps,myapp

Background : On Windows and macOS platforms, the historic behaviour of the java.awt.Desktop.browse() API was to invoke platform APIs, rather than directly invoking the default browser.

Since this behavior is now disabled, applications registered with the platform desktop may no longer be launched unless the browser also supports launching the application.

Usage : As a specific example on Windows, the new behaviour is that invoking a file:/// URL will display in the browser.

To re-enable the previous behaviour of launching the Windows Explorer application, on the command line specify

-Dawt.desktop.browse_insecure=file

To re-enable all schemes the application should specify a wild card value, which should be used with extreme caution

-Dawt.desktop.browse_insecure=*

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.

Security properties jlink plugin

A new jlink plugin has been added which allows a user to specify a file containing security property values that will override and/or add properties to the java.security configuration file in a custom runtime image. This is very useful for creating runtimes with specific security settings for applications that will be using that custom runtime. The command-line syntax takes a filename containing the properties to override or add.

For example:

jlink --security-properties props