Chapter 3. Eclipse Temurin features

Eclipse Temurin does not contain structural changes from the upstream distribution of OpenJDK.

For the list of changes and security fixes that the latest OpenJDK 11 release of Eclipse Temurin includes, see OpenJDK 11.0.25 Released.

New features and enhancements

Eclipse Temurin 11.0.25 includes the following new features and enhancements.

TLS_ECDH_* cipher suites are disabled by default

The TLS Elliptic-curve Diffie-Hellman (TLS_ECDH) cipher suites do not preserve forward secrecy and they are rarely used. OpenJDK 11.0.25 disables the TLS_ECDH cipher suites by adding the ECDH option to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. If you attempt to use the TLS_ECDH cipher suites, OpenJDK now throws an SSLHandshakeException error.

If you want to continue using the TLS_ECDH cipher suites, you can remove ECDH from the jdk.tls.disabledAlgorithms security property either by modifying the java.security configuration file or by using the java.security.properties system property.

See JDK-8279164 (JDK Bug System).

Distrust of TLS server certificates issued after 11 November 2024 and anchored by Entrust root CAs

In accordance with similar plans that Google and Mozilla recently announced, OpenJDK 11.0.25 distrusts TLS certificates that are issued after 11 November 2024 and anchored by Entrust root certificate authorities (CAs). This change in behavior includes any certificates that are branded as AffirmTrust, which are managed by Entrust.

OpenJDK will continue to trust certificates that are issued on or before 11 November 2024 until these certificates expire.

If a server’s certificate chain is anchored by an affected certificate, any attempts to negotiate a TLS session now fail with an exception to indicate that the trust anchor is not trusted. For example:

TLS server certificate issued after 2024-11-11 and anchored by a distrusted legacy Entrust root CA: CN=Entrust.net CertificationAuthority (2048), OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),O=Entrust.net

You can check whether this change affects a certificate in a JDK keystore by using the following keytool command:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If this change affects any certificate in the chain, update this certificate or contact the organization that is responsible for managing the certificate.

If you want to continue using TLS server certificates that are anchored by Entrust root certificates, you can remove ENTRUST_TLS from the jdk.security.caDistrustPolicies security property either by modifying the java.security configuration file or by using the java.security.properties system property.

These restrictions apply to the following Entrust root certificates that OpenJDK includes:

See JDK-8337664 (JDK Bug System) and JDK-8341059 (JDK Bug System).

Reduced verbose locale output in -XshowSettings launcher option

In earlier releases, the -XshowSettings launcher option printed a long list of available locales, which obscured other settings.

In OpenJDK 11.0.25, the -XshowSettings launcher option no longer prints the list of available locales by default. If you want to view all settings that relate to the available locales, you can use the -XshowSettings:locale option.

See JDK-8310201 (JDK Bug System).

SSL.com root certificates added

In OpenJDK 11.0.25, the cacerts truststore includes two SSL.com TLS root certificates:

See JDK-8341057 (JDK Bug System).

Relaxation of Java Abstract Window Toolkit (AWT) Robot specification

OpenJDK 11.0.25 is based on the latest maintenance release of the Java 11 specification. This release relaxes the specification of the following three methods in the java.awt.Robot class:

This relaxation of the specification allows these methods to fail when the desktop environment does not permit moving the mouse pointer or capturing screen content.

See JDK-8307779 (JDK Bug System).

Changes to com.sun.jndi.ldap.object.trustSerialData system property

The JDK implementation of the LDAP provider no longer supports the deserialization of Java objects by default.

In OpenJDK 11.0.25, the com.sun.jndi.ldap.object.trustSerialData system property is set to false by default. This release also increases the scope of the com.sun.jndi.ldap.object.trustSerialData property to cover the reconstruction of RMI remote objects from the javaRemoteLocation LDAP attribute.

These changes mean that transparent deserialization of Java objects now requires an explicit opt-in. From OpenJDK 11.0.25 onward, if you want to allow applications to reconstruct Java objects and RMI stubs from LDAP attributes, you must explicitly set the com.sun.jndi.ldap.object.trustSerialData property to true.

See JDK-8290367 (JDK Bug System) and JDK bug system reference ID: JDK-8332643.

HTTP client enhancements

OpenJDK 11.0.25 limits the maximum header field size that the HTTP client accepts within the JDK for all supported versions of the HTTP protocol. The header field size is computed as the sum of the size of the uncompressed header name, the size of the uncompressed header value, and an overhead of 32 bytes for each field section line. If a peer sends a field section that exceeds this limit, a java.net.ProtocolException is raised.

OpenJDK 11.0.25 introduces a jdk.http.maxHeaderSize system property that you can use to change the maximum header field size (in bytes). Alternatively, you can disable the maximum header field size by setting the jdk.http.maxHeaderSize property to zero or a negative value. The jdk.http.maxHeaderSize property is set to 393,216 bytes (that is, 384KB) by default.

JDK bug system reference ID: JDK-8328286

ClassLoadingMXBean and MemoryMXBean APIs have isVerbose() methods consistent with their setVerbose() methods

The setVerbose(boolean enabled) method for the ClassLoadingMXBean API displays the following behavior:

In earlier releases, the isVerbose() method for the ClassLoadingMXBean API checked if class+load logging was enabled at the Info level on any type of log output, not just stdout. In this situation, if you enabled logging to a file by using the java -Xlog option, the isVerbose() method returned true even if setVerbose(false) was called, which resulted in counterintuitive behavior. The isVerbose() method for the MemoryMXBean API also displayed similar counterintuitive behavior.

From OpenJDK 11.0.25 onward, the ClassLoadingMXBean.isVerbose() and MemoryMXBean.isVerbose() methods display the following behavior:

See JDK-8338139 (JDK Bug System).

Revised on 2024-10-30 10:44:14 UTC