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 17 release of Eclipse Temurin includes, see OpenJDK 17.0.12 Released . New features and enhancements Review the following release notes to understand new features and feature enhancements included with the Eclipse Temurin 17.0.12 release: 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 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. Note 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 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. Note 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 USDORIGIN 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 the LD_LIBRARY_PATH environment variable. If a binary specifies search paths by using DT_RUNPATH , these paths are searched only after paths that are specified in LD_LIBRARY_PATH . This means that the use of DT_RUNPATH can allow JDK internal libraries to be overridden by any libraries of the same name that are specified in LD_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 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 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 OpenJDK 17.0.12, the -XshowSettings launcher option includes a security category, which allows the following arguments to be passed: Argument Details -XshowSettings:security or -XshowSettings:security:all Show all security settings and continue. -XshowSettings:security:properties Show security properties and continue. -XshowSettings:security:providers Show static security provider settings and continue. -XshowSettings:security:tls 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 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, 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 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 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) . Revised on 2024-08-02 13:39:00 UTC

Commands: