JDK 11.0.13 Release Notes

Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each deserialization stream. The behavior is a strict subset of JEP 415: Context-Specific Deserialization Filters to allow a filter factory to be configured using a property configured on the command line or in the security properties file.

The behavior is opt-in based on the presence of the jdk.serialFilterFactory system property on the command line or the jdk.serialFilterFactory security property. If set, the JVM-wide filter factory selects the filter for each stream when the stream is constructed and when a stream-specific filter is set.

The JVM-wide filter factory is a java.util.function.BinaryOperator<java.io.ObjectInputFilter> function invoked when each ObjectInputStream is constructed and when the stream-specific filter is set using ObjectInputStream.setObjectInputFilter(ObjectInputFilter). The parameters are the current filter and a requested filter and the function returns the filter to be used for the stream. When invoked from the ObjectInputStream constructors, the first parameter is null and the second parameter is the static JVM-wide filter. When invoked from ObjectInputStream.setObjectInputFilter, the first parameter is the filter currently set on the stream (which was set in the constructor), and the second parameter is the filter given to ObjectInputStream.setObjectInputFilter.

A typical filter factory should use or merge the static JVM-wide filter with other application and context specific filters and the stream-specific filter, if one is set on the stream. The filter factory implementation can also use any contextual information at its disposal, for example, extracted from the application thread context, or its call stack, to compose and combine a new filter. It is not restricted to only use its two parameters.

Refer to Context-Specific Deserialization Filter and Serialization Filtering Guide for details.

The following root certificate from IdenTrust has been removed from the cacerts keystore:

+ alias name "identrustdstx3 [jdk]"

  Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.

The experimental Java-based JIT compiler, Graal JEP317, has been removed. Attempting to use it produces a JVMCI error: JVMCI compiler 'graal' not found.

The Java Ahead-of-Time compilation experimental tool jaotc has been removed. Using HotSpot VM AOT options defined by JEP295 produce "Unrecognized VM option" error on VM initialization.

Developers who wish to test the Graal compiler for either AOT or JIT compilation should use GraalVM.

This release doesn't correctly identify Windows 11. The property os.name is set to Windows 10 on Windows 11. In HotSpot error logs, the OS is identified as Windows 10; however, the HotSpot error log does show the Build number. Windows 11 has Build 22000.194 or above.

On the Linux platform, the names of JDK packages provided by Java RPM and DEB installers have been changed. Names of JDK packages follow the jdk-<feature_release_version> pattern instead of the jdk-<update_release_version> pattern that was previously used. For example, the new names of JDK 11, 16, and 17 packages are jdk-11, jdk-16, and jdk-17 respectively.

The change to package names disables side-by-side installation of multiple JDKs of the same release family. Only one JDK per release family can be installed on a system with RPM and DEB installers.

If a user wants to have multiple update releases from the same family, the user must download the tar.gz bundles.

The default priority order of the cipher suites for TLS 1.0 to TLS 1.3 has been adjusted.

For TLS 1.3, TLS_AES_256_GCM_SHA384 is now preferred over TLS_AES_128_GCM_SHA256.

For TLS 1.0 to TLS 1.2, some of the intermediate suites have been lowered in priority as follows:

• Cipher suites that do not preserve forward secrecy have been moved lower in priority than those that do support forward secrecy.
• Cipher suites that use SHA-1 have been moved lower in priority.
See JDK-8163326

The scope of the com.sun.jndi.ldap.object.trustSerialData system property has been extended to control the deserialization of java objects from the javaReferenceAddress LDAP attribute. This system property now controls the deserialization of java objects from the javaSerializedData and javaReferenceAddress LDAP attributes.

To prevent deserialization of java objects from these attributes, the system property can be set to false. By default, the deserialization of java objects from javaSerializedData and javaReferenceAddress attributes is allowed.

This release doesn't correctly identify Windows Server 2022. The property os.name is set to Windows Server 2019 on Windows Server 2022. In HotSpot error logs the OS is identified as Windows Server 2019; however, the HotSpot error log does show the Build number. Windows Server 2022 has Build 20348, or above.

The gencert command of the keytool utility has been updated to create AKID from the SKID of the issuing certificate as specified by RFC 5280.

The SunPKCS11 security provider can now be initialized with NSS when FIPS-enabled external modules are configured in the Security Modules Database (NSSDB). Before this change, when such a library was configured for NSS in non-FIPS mode, the SunPKCS11 provider would throw a RuntimeException with the message "FIPS flag set for non-internal module".

This change allows the JDK to work properly with recent NSS releases in GNU/Linux operating systems when the system-wide FIPS policy is turned on.