Chapter 2. 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 21 release of Eclipse Temurin includes, see OpenJDK 21.0.4 Released.

New features and enhancements

Review the following release notes to understand new features and feature enhancements included with the Eclipse Temurin 21.0.4 release:

-XshowSettings launcher option includes a security category

In OpenJDK 21.0.4, 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 OpenJDK 21.0.4, the cacerts truststore includes two GlobalSign TLS root certificates:

See JDK-8316138 (JDK Bug System).

Fallback option for POST-only OCSP requests

JDK-8175903, which was introduced in 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.

OpenJDK 21.0.4 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).

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 OpenJDK 21.0.4, to ensure that DT_RPATH is used, the --disable-new-dtags option is explicitly passed to the linker.

See JDK-8326891 (JDK Bug System).

Jpackage tool resolves symbolic links before passing file paths to dpkg

On Debian and Ubuntu systems, the jpackage tool uses the dpkg -S command to check which package provides a specific file. However, on newer Debian and Ubuntu systems, the dpkg -S command does not resolve symbolic links.

In OpenJDK 21.0.4, jpackage resolves symbolic links before passing the real file path to dpkg.

See JDK-8295111 (JDK Bug System).

G1 garbage collector ignores existing eden regions for heap resizing during the Remark phase

To comply with -XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio settings, the Garbage-First (G1) garbage collector adjusts the Java heap size during the Remark phase of garbage collection, keeping the number of free regions within these limits.

In earlier releases, eden regions were considered to be occupied or full for the purpose of calculating Java heap size. This meant the heap size was dependent on the eden occupancy at the time the Remark phase was run. However, after the next garbage collection, these eden regions were empty.

In OpenJDK 21.0.4, eden regions are considered to be empty or free during the Remark phase calculation. This enhancement means that the G1 garbage collector now expands the Java heap less aggressively and more deterministically, because the number of free regions does not vary as much. This enhancement also aligns Java heap sizing with the full garbage collection heap sizing. However, this might potentially lead to more frequent garbage collection.

See JDK-8314573 (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 OpenJDK 21.0.4, multiple threads are used, which helps to remove any scalability bottleneck.

See JDK-8315503 (JDK Bug System).

Fix for long garbage collection pauses in Stop-the-World collectors

In early releases of OpenJDK 21, applications could experience long pause times during stop-the-world (STW) garbage collection. This issue affected various phases of the collection pauses, including Class Unloading, Root Scanning, and CodeCache Unloading, in all types of STW garbage collectors, such as the Serial, Parallel, and G1 collectors.

OpenJDK 21.0.4 resolves these performance issues in STW collectors.

See JDK-8333832 (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 OpenJDK 21.0.4 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).

Revised on 2024-08-02 13:44:35 UTC