Release notes for Red Hat build of OpenJDK 17.0.12

Red Hat will support select major versions of Red Hat build of OpenJDK in its products. For consistency, these versions remain similar to Oracle JDK versions that are designated as long-term support (LTS).

A major version of Red Hat build of OpenJDK will be supported for a minimum of six years from the time that version is first introduced. For more information, see the OpenJDK Life Cycle and Support Policy.

Red Hat build of OpenJDK in Red Hat Enterprise Linux contains a number of structural changes from the upstream distribution of OpenJDK. The Microsoft Windows version of Red Hat build of OpenJDK attempts to follow Red Hat Enterprise Linux updates as closely as possible.

The following list details the most notable Red Hat build of OpenJDK 17 changes:

From October 2024 onward, Red Hat plans to introduce naming changes for some files that are distributed as part of Red Hat build of OpenJDK releases for Windows Server platforms.

These file naming changes will affect both the .zip archive and .msi installers that Red Hat provides for the JDK, JRE and debuginfo packages for Red Hat build of OpenJDK versions 8, 11, and 17.

The aim of this change is to adopt a common naming convention that is consistent across all versions of OpenJDK that Red Hat supports. Red Hat build of OpenJDK versions 8, 11, and 17 will be aligned with the naming convention that Red Hat has already adopted for Red Hat build of OpenJDK 21. This means that Red Hat build of OpenJDK 21 will not require any naming changes.

These planned changes do not affect the files for the Linux portable builds of any Red Hat build of OpenJDK version.

Red Hat build of OpenJDK 17.0.12 is the last release where Red Hat plans to use the old naming convention for Windows artifacts. The following list provides an example of how the planned naming changes will affect each file for future releases of Red Hat build of OpenJDK 17:

The latest Red Hat build of OpenJDK 17 release might include new features. Additionally, the latest release might enhance, deprecate, or remove features that originated from previous Red Hat build of OpenJDK 17 releases.

Red Hat build of OpenJDK enhancements

Red Hat build of OpenJDK 17 provides enhancements to features originally created in previous releases of Red Hat build of OpenJDK.

Fallback option for POST-only OCSP requests

JDK-8175903, which was introduced in Red Hat build of OpenJDK 17, added support for using the HTTP GET method for Online Certificate Status Protocol (OCSP) requests. This feature was enabled unconditionally for small requests.

The Internet Engineering Task Force (IETF) RFC 5019 and RFC 6960 explicitly allow and recommend the use of HTTP GET requests. However, some OCSP responders do not work well with these types of requests.

Red Hat build of OpenJDK 17.0.12 introduces a JDK system property, com.sun.security.ocsp.useget. By default, this property is set to true, which retains the current behavior of using GET requests for small requests. If this property is set to false, only HTTP POST requests are used, regardless of size.

See JDK-8328638 (JDK Bug System).

DTLS 1.0 is disabled by default

OpenJDK 9 introduced support for both version 1.0 and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol (JEP-219). DTLSv1.0, which is based on TLS 1.1, is no longer recommended for use, because this protocol is considered weak and insecure by modern standards. In Red Hat build of OpenJDK 17.0.12, if you attempt to use DTLSv1.0, the JDK throws an SSLHandshakeException by default.

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

See JDK-8256660 (JDK Bug System).

RPATH preferred over RUNPATH for $ORIGIN runtime search paths in internal JDK binaries

Native executables and libraries in the JDK use embedded runtime search paths (rpaths) to locate required internal JDK native libraries. On Linux systems, binaries can specify these search paths by using either DT_RPATH or DT_RUNPATH.

In earlier releases, the type of runtime search path used was based on the default search path for the dynamic linker. In Red Hat build of OpenJDK 17.0.12, to ensure that DT_RPATH is used, the --disable-new-dtags option is explicitly passed to the linker.

See JDK-8326891 (JDK Bug System).

TrimNativeHeapInterval option available as a product switch

Red Hat build of OpenJDK 17.0.12 provides the -XX:TrimNativeHeapInterval=ms option as an official product switch. This enhancement enables the JVM to trim the native heap at specified intervals (in milliseconds) on supported platforms. Currently, the only supported platform for this enhancement is Linux with glibc.

You can disable trimming by setting TrimNativeHeapInterval=0. The trimming feature is disabled by default.

See JDK-8325496 (JDK Bug System).

-XshowSettings launcher option includes a security category

In Red Hat build of OpenJDK 17.0.12, the -XshowSettings launcher option includes a security category, which allows the following arguments to be passed:

If third-party security providers are included in the application class path or module path, and configured in the java.security file, the output includes these third-party security providers.

See JDK-8281658 (JDK Bug System).

GlobalSign R46 and E46 root certificates added

In Red Hat build of OpenJDK 17.0.12, the cacerts truststore includes two GlobalSign TLS root certificates:

See JDK-8316138 (JDK Bug System).

Fix for long garbage collection pauses due to imbalanced iteration during the Code Root Scan phase

The Code Root Scan phase of garbage collection finds references to Java objects within compiled code. To speed up this process, a cache is maintained within each region of the compiled code that contains references into the Java heap.

On the assumption that the set of references was small, previous releases used a single thread per region to iterate through these references. This single-threaded approach introduced a scalability bottleneck, where performance could be reduced if a specific region contained a large number of references.

In Red Hat build of OpenJDK 17.0.12, multiple threads are used, which helps to remove any scalability bottleneck.

See JDK-8315503 (JDK Bug System).

Change in behavior for AWT headless mode detection on Windows

In earlier releases, unless the java.awt.headless system property was set to true, a call to java.awt.GraphicsEnvironment.isHeadless() returned false on Windows Server platforms.

From Red Hat build of OpenJDK 17.0.12 onward, unless the java.awt.headless property is explicitly set to false and if no valid monitor is detected on the current system at runtime, a call to java.awt.GraphicsEnvironment.isHeadless() returns true on Windows Server platforms. A valid monitor might not be detected, for example, if a session was initiated by a service or by PowerShell remoting.

This change in behavior means that applications running under these conditions, which previously expected to run in a headful context, might now encounter unexpected HeadlessException errors being thrown by Abstract Window Toolkit (AWT) operations.

You can reinstate the old behavior by setting the java.awt.headless property to false. However, if applications are running in headful mode and a valid display is not available, these applications are likely to continue experiencing unexpected issues.

See JDK-8185862 (JDK Bug System).

The following advisories are issued to document bug fixes and CVE fixes included in this release:

Revised on 2024-07-22 15:54:53 UTC