Red Hat Summit이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Release notes for Eclipse Temurin 17.0.12
Abstract
Preface
Open Java Development Kit (OpenJDK) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). Eclipse Temurin is available in four LTS versions: OpenJDK 8u, OpenJDK 11u, OpenJDK 17u, and OpenJDK 21u.
Binary files for Eclipse Temurin are available for macOS, Microsoft Windows, and multiple Linux x86 Operating Systems including Red Hat Enterprise Linux and Ubuntu.
Providing feedback on Red Hat build of OpenJDK documentation
To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account.
Procedure
- Click the following link to create a ticket.
- Enter a brief description of the issue in the Summary.
- Provide a detailed description of the issue or enhancement in the Description. Include a URL to where the issue occurs in the documentation.
- Clicking Create creates and routes the issue to the appropriate documentation team.
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Chapter 1. Support policy for Eclipse Temurin
Red Hat will support select major versions of Eclipse Temurin in its products. For consistency, these versions remain similar to Oracle JDK versions that Oracle designates as long-term support (LTS).
A major version of Eclipse Temurin will be supported for a minimum of six years from the time that version is first introduced. For more information, see the Eclipse Temurin Life Cycle and Support Policy.
RHEL 6 reached the end of life in November 2020. Because of this, Eclipse Temurin does not support RHEL 6 as a supported configuration.
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.
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.
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 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 |
|---|---|
|
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 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 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
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}