Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Release notes for Red Hat build of OpenJDK 11.0.25

Red Hat build of OpenJDK 11

Red Hat Customer Content Services

Abstract

The Release notes for Red Hat build of OpenJDK 11.0.25 document provides an overview of new features in Red Hat build of OpenJDK 11 and a list of potential known issues and possible workarounds.

Preface
Copy link

Open Java Development Kit (OpenJDK) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in four versions: 8u, 11u, 17u, and 21u.

Packages for the Red Hat build of OpenJDK are made available on Red Hat Enterprise Linux and Microsoft Windows and shipped as a JDK and JRE in the Red Hat Ecosystem Catalog.

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

  1. Click the following link to create a ticket.
  2. Enter a brief description of the issue in the Summary.
  3. Provide a detailed description of the issue or enhancement in the Description. Include a URL to where the issue occurs in the documentation.
  4. Clicking Create creates and routes the issue to the appropriate documentation team.

Making open source more inclusive
Copy link

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.

Important

The 11.0.25 release is the last release of Red Hat build of OpenJDK 11 that Red Hat plans to fully support. The full support for Red Hat build of OpenJDK 11 ends on 31 October 2024. See the Product Life Cycles page for details.

Red Hat will provide extended life cycle support (ELS) phase 1 support for Red Hat build of OpenJDK 11 until 31 October 2027. For more information about product life cycle phases and available support levels, see Life Cycle Phases.

For information about migrating to Red Hat build of OpenJDK version 17 or 21, see Migrating to Red Hat build of OpenJDK 17 from earlier versions or Migrating to Red Hat build of OpenJDK 21 from earlier versions.

Red Hat will support select major versions of Red Hat build of OpenJDK in its products. For consistency, these are the same versions that Oracle designates as long-term support (LTS) for the Oracle JDK.

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.

Note

RHEL 6 reached the end of life in November 2020. Because of this, Red Hat build of OpenJDK is not supporting RHEL 6 as a supported configuration.

Important

Full support for Red Hat build of OpenJDK 11 ends on 31 October 2024. For more information, see Red Hat build of OpenJDK 11 - End of full support.

Chapter 3. Differences from upstream OpenJDK 11
Copy link

Red Hat build of OpenJDK in Red Hat Enterprise Linux (RHEL) 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 RHEL updates as closely as possible.

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

  • FIPS support. Red Hat build of OpenJDK 11 automatically detects whether RHEL is in FIPS mode and automatically configures Red Hat build of OpenJDK 11 to operate in that mode. This change does not apply to Red Hat build of OpenJDK builds for Microsoft Windows.
  • Cryptographic policy support. Red Hat build of OpenJDK 11 obtains the list of enabled cryptographic algorithms and key size constraints from RHEL. These configuration components are used by the Transport Layer Security (TLS) encryption protocol, the certificate path validation, and any signed JARs. You can set different security profiles to balance safety and compatibility. This change does not apply to Red Hat build of OpenJDK builds for Microsoft Windows.
  • Red Hat build of OpenJDK on RHEL dynamically links against native libraries such as zlib for archive format support and libjpeg-turbo, libpng, and giflib for image support. RHEL also dynamically links against Harfbuzz and Freetype for font rendering and management.
  • The src.zip file includes the source for all the JAR libraries shipped with Red Hat build of OpenJDK.
  • Red Hat build of OpenJDK on RHEL uses system-wide timezone data files as a source for timezone information.
  • Red Hat build of OpenJDK on RHEL uses system-wide CA certificates.
  • Red Hat build of OpenJDK on Microsoft Windows includes the latest available timezone data from RHEL.
  • Red Hat build of OpenJDK on Microsoft Windows uses the latest available CA certificate from RHEL.

Chapter 4. Red Hat build of OpenJDK features
Copy link

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

Important

Full support for Red Hat build of OpenJDK 11 ends on 31 October 2024. For more information, see Red Hat build of OpenJDK 11 - End of full support.

Red Hat build of OpenJDK new features and enhancements

Review the following release notes to understand new features and feature enhancements that Red Hat build of OpenJDK 11.0.25 provides:

TLS_ECDH_* cipher suites are disabled by default

The TLS Elliptic-curve Diffie-Hellman (TLS_ECDH) cipher suites do not preserve forward secrecy and they are rarely used. Red Hat build of OpenJDK 11.0.25 disables the TLS_ECDH cipher suites by adding the ECDH option to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. If you attempt to use the TLS_ECDH cipher suites, Red Hat build of OpenJDK now throws an SSLHandshakeException error.

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

Note

Continued use of the TLS_ECDH cipher suites is at your own risk.

ECDH cipher suites that use RC4 were disabled in an earlier release. This change does not affect the TLS_ECDHE cipher suites, which remain enabled by default.

See JDK-8279164 (JDK Bug System).

Distrust of TLS server certificates issued after 11 November 2024 and anchored by Entrust root CAs

In accordance with similar plans that Google and Mozilla recently announced, Red Hat build of OpenJDK 11.0.25 distrusts TLS certificates that are issued after 11 November 2024 and anchored by Entrust root certificate authorities (CAs). This change in behavior includes any certificates that are branded as AffirmTrust, which are managed by Entrust.

Red Hat build of OpenJDK will continue to trust certificates that are issued on or before 11 November 2024 until these certificates expire.

If a server’s certificate chain is anchored by an affected certificate, any attempts to negotiate a TLS session now fail with an exception to indicate that the trust anchor is not trusted. For example: 

TLS server certificate issued after 2024-11-11 and anchored by a distrusted legacy Entrust root CA: CN=Entrust.net CertificationAuthority (2048), OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),O=Entrust.net
Copy to Clipboard Toggle word wrap

You can check whether this change affects a certificate in a JDK keystore by using the following keytool command:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If this change affects any certificate in the chain, update this certificate or contact the organization that is responsible for managing the certificate.

If you want to continue using TLS server certificates that are anchored by Entrust root certificates, you can remove ENTRUST_TLS from the jdk.security.caDistrustPolicies security property either by modifying the java.security configuration file or by using the java.security.properties system property.

Note

Continued use of the distrusted TLS server certificates is at your own risk.

These restrictions apply to the following Entrust root certificates that Red Hat build of OpenJDK includes:

Certificate 1
  • Alias name: entrustevca [jdk]
  • Distinguished name: CN=Entrust Root Certification Authority, OU=(c) 2006 Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, O=Entrust, Inc., C=US
  • SHA256: 73:C1:76:43:4F:1B:C6:D5:AD:F4:5B:0E:76:E7:27:28:7C:8D:E5:76:16:C1:E6:E6:14:1A:2B:2C:BC:7D:8E:4C
Certificate 2
  • Alias name: entrustrootcaec1 [jdk]
  • Distinguished name: CN=Entrust Root Certification Authority - EC1, OU=(c) 2012 Entrust, Inc. - for authorized use only, OU=See www.entrust.net/legal-terms, O=Entrust, Inc., C=US
  • SHA256: 02:ED:0E:B2:8C:14:DA:45:16:5C:56:67:91:70:0D:64:51:D7:FB:56:F0:B2:AB:1D:3B:8E:B0:70:E5:6E:DF:F5
Certificate 3
  • Alias name: entrustrootcag2 [jdk]
  • Distinguished name: CN=Entrust Root Certification Authority - G2, OU=(c) 2009 Entrust, Inc. - for authorized use only, OU=See www.entrust.net/legal-terms, O=Entrust, Inc., C=US
  • SHA256: 43:DF:57:74:B0:3E:7F:EF:5F:E4:0D:93:1A:7B:ED:F1:BB:2E:6B:42:73:8C:4E:6D:38:41:10:3D:3A:A7:F3:39
Certificate 4
  • Alias name: entrustrootcag4 [jdk]
  • Distinguished name: CN=Entrust Root Certification Authority - G4, OU=(c) 2015 Entrust, Inc. - for authorized use only, OU=See www.entrust.net/legal-termsO=Entrust, Inc., C=US
  • SHA256: DB:35:17:D1:F6:73:2A:2D:5A:B9:7C:53:3E:C7:07:79:EE:32:70:A6:2F:B4:AC:42:38:37:24:60:E6:F0:1E:88
Certificate 5
  • Alias name: entrust2048ca [jdk]
  • Distinguished name: CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net
  • SHA256: 6D:C4:71:72:E0:1C:BC:B0:BF:62:58:0D:89:5F:E2:B8:AC:9A:D4:F8:73:80:1E:0C:10:B9:C8:37:D2:1E:B1:77
Certificate 6
  • Alias name: affirmtrustcommercialca [jdk]
  • Distinguished name: CN=AffirmTrust Commercial, O=AffirmTrust, C=US
  • SHA256: 03:76:AB:1D:54:C5:F9:80:3C:E4:B2:E2:01:A0:EE:7E:EF:7B:57:B6:36:E8:A9:3C:9B:8D:48:60:C9:6F:5F:A7
Certificate 7
  • Alias name: affirmtrustnetworkingca [jdk]
  • Distinguished name: CN=AffirmTrust Networking, O=AffirmTrust, C=US
  • SHA256: 0A:81:EC:5A:92:97:77:F1:45:90:4A:F3:8D:5D:50:9F:66:B5:E2:C5:8F:CD:B5:31:05:8B:0E:17:F3:F0B4:1B
Certificate 8
  • Alias name: affirmtrustpremiumca [jdk]
  • Distinguished name: CN=AffirmTrust Premium, O=AffirmTrust, C=US
  • SHA256: 70:A7:3F:7F:37:6B:60:07:42:48:90:45:34:B1:14:82:D5:BF:0E:69:8E:CC:49:8D:F5:25:77:EB:F2:E9:3B:9A
Certificate 9
  • Alias name: affirmtrustpremiumeccca [jdk]
  • Distinguished name: CN=AffirmTrust Premium ECCO=AffirmTrust, C=US
  • SHA256: BD:71:FD:F6:DA:97:E4:CF:62:D1:64:7A:DD:25:81:B0:7D:79:AD:F8:39:7E:B4:EC:BA:9C:5E:84:88:82:14:23

See JDK-8337664 (JDK Bug System) and JDK-8341059 (JDK Bug System).

Reduced verbose locale output in -XshowSettings launcher option

In earlier releases, the -XshowSettings launcher option printed a long list of available locales, which obscured other settings.

In Red Hat build of OpenJDK 11.0.25, the -XshowSettings launcher option no longer prints the list of available locales by default. If you want to view all settings that relate to the available locales, you can use the -XshowSettings:locale option.

See JDK-8310201 (JDK Bug System).

SSL.com root certificates added

In Red Hat build of OpenJDK 11.0.25, the cacerts truststore includes two SSL.com TLS root certificates:

Certificate 1
  • Name: SSL.com
  • Alias name: ssltlsrootecc2022
  • Distinguished name: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
Certificate 2
  • Name: SSL.com
  • Alias name: ssltlsrootrsa2022
  • Distinguished name: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US

See JDK-8341057 (JDK Bug System).

Relaxation of Java Abstract Window Toolkit (AWT) Robot specification

Red Hat build of OpenJDK 11.0.25 is based on the latest maintenance release of the Java 11 specification. This release relaxes the specification of the following three methods in the java.awt.Robot class:

  • mouseMove(int,int)
  • getPixelColor(int,int)
  • createScreenCapture(Rectangle)

This relaxation of the specification allows these methods to fail when the desktop environment does not permit moving the mouse pointer or capturing screen content.

See JDK-8307779 (JDK Bug System).

Changes to com.sun.jndi.ldap.object.trustSerialData system property

The JDK implementation of the LDAP provider no longer supports the deserialization of Java objects by default.

In Red Hat build of OpenJDK 11.0.25, the com.sun.jndi.ldap.object.trustSerialData system property is set to false by default. This release also increases the scope of the com.sun.jndi.ldap.object.trustSerialData property to cover the reconstruction of RMI remote objects from the javaRemoteLocation LDAP attribute.

These changes mean that transparent deserialization of Java objects now requires an explicit opt-in. From Red Hat build of OpenJDK 11.0.25 onward, if you want to allow applications to reconstruct Java objects and RMI stubs from LDAP attributes, you must explicitly set the com.sun.jndi.ldap.object.trustSerialData property to true.

See JDK-8290367 (JDK Bug System) and JDK-8332643 (JDK Bug System).

HTTP client enhancements

Red Hat build of OpenJDK 11.0.25 limits the maximum header field size that the HTTP client accepts within the JDK for all supported versions of the HTTP protocol. The header field size is computed as the sum of the size of the uncompressed header name, the size of the uncompressed header value, and an overhead of 32 bytes for each field section line. If a peer sends a field section that exceeds this limit, a java.net.ProtocolException is raised.

Red Hat build of OpenJDK 11.0.25 introduces a jdk.http.maxHeaderSize system property that you can use to change the maximum header field size (in bytes). Alternatively, you can disable the maximum header field size by setting the jdk.http.maxHeaderSize property to zero or a negative value. The jdk.http.maxHeaderSize property is set to 393,216 bytes (that is, 384KB) by default.

See JDK-8328286 (JDK Bug System).

ClassLoadingMXBean and MemoryMXBean APIs have isVerbose() methods consistent with their setVerbose() methods

The setVerbose(boolean enabled) method for the ClassLoadingMXBean API displays the following behavior:

  • If enabled is true, the setVerbose method sets class+load* logging on standard output (stdout) at the Info level.
  • If enabled is false, the setVerbose method disables class+load* logging on stdout.

In earlier releases, the isVerbose() method for the ClassLoadingMXBean API checked if class+load logging was enabled at the Info level on any type of log output, not just stdout. In this situation, if you enabled logging to a file by using the java -Xlog option, the isVerbose() method returned true even if setVerbose(false) was called, which resulted in counterintuitive behavior. The isVerbose() method for the MemoryMXBean API also displayed similar counterintuitive behavior.

From Red Hat build of OpenJDK 11.0.25 onward, the ClassLoadingMXBean.isVerbose() and MemoryMXBean.isVerbose() methods display the following behavior:

  • ClassLoadingMXBean::isVerbose() returns true only if class+load* logging is enabled at the Info level (or higher) specifically on standard output (stdout).
  • MemoryMXBean::isVerbose() returns true only if garbage collector logging is enabled at the Info level (or higher) on stdout.

See JDK-8338139 (JDK Bug System).

Changes to naming convention for Windows build artifacts

This release introduces naming changes for some files that are distributed as part of Red Hat build of OpenJDK 11 for Windows Server platforms.

These file naming changes 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 11.

The aim of this change is to adopt a common naming convention that is consistent across the different versions of OpenJDK that Red Hat currently supports. This means that Red Hat build of OpenJDK 11 is now aligned with the naming convention that Red Hat has already adopted for Red Hat build of OpenJDK 21.

These changes do not affect the files for Linux portable builds.

The following list provides an example of how these naming changes affect files in Red Hat build of OpenJDK 11:

MSI installer for JDK package

  • Old naming format for Red Hat build of OpenJDK 11.0.24 or earlier:

    java-11-openjdk-<version>.<build>.windows.redhat.x86_64.msi

  • New naming format for Red Hat build of OpenJDK 11.0.25 or later:

    java-11-openjdk-<version>.<build>.win.jdk.x86_64.msi

.zip archive for JDK package

  • Old naming format for Red Hat build of OpenJDK 11.0.24 or earlier:

    java-11-openjdk-<version>.<build>.windows.redhat.x86_64.zip

  • New naming format for Red Hat build of OpenJDK 11.0.25 or later:

    java-11-openjdk-<version>.<build>.win.jdk.x86_64.zip

MSI installer for JRE package

  • Old naming format for Red Hat build of OpenJDK 11.0.24 or earlier:

    java-11-openjdk-jre-<version>.<build>.windows.redhat.x86_64.msi

  • New naming format for Red Hat build of OpenJDK 11.0.25 or later:

    java-11-openjdk-<version>.<build>.win.jre.x86_64.msi

.zip archive for JRE package

  • Old naming format for Red Hat build of OpenJDK 11.0.24 or earlier:

    java-11-openjdk-jre-<version>.<build>.windows.redhat.x86_64.zip

  • New naming format for Red Hat build of OpenJDK 11.0.25 or later:

    java-11-openjdk-<version>.<build>.win.jre.x86_64.zip

.zip archive for debuginfo package

  • Old naming format for Red Hat build of OpenJDK 11.0.24 or earlier:

    java-11-openjdk-<version>.<build>.windows.redhat.x86_64.debuginfo.zip

  • New naming format for Red Hat build of OpenJDK 11.0.25 or later:

    java-11-openjdk-<version>.<build>.win.debuginfo.x86_64.zip

Chapter 5. Advisories related to this release
Copy link

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

Revised on 2024-10-18 15:20:05 UTC

Legal Notice
Copy link

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat