Chapter 4. Red Hat build of OpenJDK features
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.
For all the other changes and security fixes, see OpenJDK 17.0.12 Released.
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.
This fallback option for POST-only OCSP requests is a non-standard feature, which might be removed in a future release if the use of HTTP GET requests with OCSP responders no longer causes any issues.
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.
Continued use of DTLSv1.0 is not recommended and is at the user’s own risk.
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.
-
If a binary specifies search paths by using
DT_RPATH, these paths are searched before any paths that are specified in theLD_LIBRARY_PATHenvironment variable. -
If a binary specifies search paths by using
DT_RUNPATH, these paths are searched only after paths that are specified inLD_LIBRARY_PATH. This means that the use ofDT_RUNPATHcan allow JDK internal libraries to be overridden by any libraries of the same name that are specified inLD_LIBRARY_PATH, which is undesirable from a security perspective.
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:
| Argument | Details |
|---|---|
|
or
| Show all security settings and continue. |
|
| Show security properties and continue. |
|
| Show static security provider settings and continue. |
|
| Show TLS-related security settings and continue. |
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:
- Certificate 1
- Name: GlobalSign
- Alias name: globalsignr46
- Distinguished name: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE
- Certificate 2
- Name: GlobalSign
- Alias name: globalsigne46
- Distinguished name: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
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.
