Chapter 2. Eclipse Temurin features


Eclipse Temurin does not contain structural changes from the upstream distribution of OpenJDK.

For more information about the changes and security fixes in the latest OpenJDK 17 release of Eclipse Temurin, see OpenJDK 17.0.17 Released.

2.1. New features and enhancements

Eclipse Temurin 17.0.17 includes the following new features and enhancements.

Improved HTTP/2 flow control checks

OpenJDK 17.0.17 enhances the HTTP/2 client implementation in java.net.http.HttpClient objects to report flow control errors to the server. This behavior is typically transparent in most situations. However, it might mean that streams are reset or connections are closed when connecting to an HTTP/2 server that does not correctly handle these errors.

You can use the following existing properties to adjust flow control limits:

jdk.httpclient.connectionWindowSize
  • Specifies the HTTP/2 client connection window size in bytes
  • Default value: 67108864 (2^26, 64 MiB)
  • Range: 2^16-1 to 2^31-1
jdk.httpclient.windowSize
  • Specifies the HTTP/2 client stream window size in bytes
  • Default value: 16777216 (2^24, 16 MiB)
  • Range: 2^14 to 2^31-1

If you specify an invalid value, the default value is used. This enhancement guarantees that the actual value for the connection window size is not smaller than the stream window size.

See JDK-8342075 (JDK Bug System).

XML Security for Java updated to Apache Santuario 3.0.5

From OpenJDK 17.0.17 onward, the XML signature implementation is based on Apache Santuario 3.0.5. This supersedes the behavior in earlier releases where the XML signature implementation was based on Apache Santuario 3.0.3.

This enhancement introduces the following four SHA-3-based ECDSA SignatureMethod algorithms:

  • ECDSA_SHA3_224
  • ECDSA_SHA3_256
  • ECDSA_SHA3_384
  • ECDSA_SHA3_512

Because the SignatureMethod constants for these algorithms are available in Java 25 only, use the following equivalent string literal values to obtain instances of these algorithms:

  • http://www.w3.org/2021/04/xmldsig-more#ecdsa-sha3-224
  • http://www.w3.org/2021/04/xmldsig-more#ecdsa-sha3-256
  • http://www.w3.org/2021/04/xmldsig-more#ecdsa-sha3-384
  • http://www.w3.org/2021/04/xmldsig-more#ecdsa-sha3-512

See JDK-8344137 (JDK Bug System).

LDAP and RMI protocol-specific object factory filters for JNDI

The OpenJDK security updates in April 2021 introduced jdk.jndi.object.factoriesFilter as both a system property and a security property. This property is used to control whether a specific object factory is permitted to instantiate objects from the remote object references that are obtained by using the protocols in the Java Naming and Directory Interface (JNDI) API. By default, this property was set to an asterisk (*) wildcard value to allow all object factory classes.

OpenJDK 17.0.17 introduces the following two additional properties to provide more granular control of the Lightweight Directory Access Protocol (LDAP) and Remote Method Invocation (RMI) protocols that JNDI uses:

  • jdk.jndi.ldap.object.factoriesFilter

    This property filters object factory classes that are used with object references obtained from a JNDI/LDAP context. The default value is java.naming/com.sun.jndi.ldap.**;!* to allow only object factories that are defined in the java.naming module.

  • jdk.jndi.rmi.object.factoriesFilter

    This property filters object factory classes that are used with object references obtained from a JNDI/RMI context. The default value is jdk.naming.rmi/com.sun.jndi.rmi.**;!* to allow only object factories that are defined in the jdk.naming.rmi module.

Each of these new properties is also available as both a system property and a security property. When using the default values, the system property takes precedence over the security property.

Each filter can return a result of ALLOWED, REJECTED, or UNDECIDED by using the Status enumeration from the java.io.ObjectInputFilter interface.

For an object factory class to be accepted, it must meet both of the following conditions:

  • Either the global filter, jdk.jndi.object.factoriesFilter, or the filter for the specific protocol must return ALLOWED.
  • Neither the global filter, jdk.jndi.object.factoriesFilter, nor the filter for the specific protocol must return REJECTED.

If an application depends on custom object factories to instantiate objects from remote RMI or LDAP object references, ensure that you update the appropriate filter property to allow these factories to function. Otherwise, the filter will block the factory and a plain javax.naming.Reference instance is returned instead.

See JDK-8290368 (JDK Bug System).

Mechanism for disabling different parts of the TLS cipher suite based on pattern matching

In earlier releases, the mechanisms for disabling TLS algorithms were either too general or too specific. For example, if you disabled an algorithm such as RSA, the JDK disabled all cipher suites that used this algorithm. In this situation, the only alternative was to disable each cipher suite specifically.

From OpenJDK 17.0.17 onward, the jdk.tls.disabledAlgorithms security property in the java.security configuration file supports asterisk (*) wildcard characters for patterns that start with "TLS_". For example, TLS_RSA_* disables all cipher suites that start with TLS_RSA_.

See JDK-8341964 (JDK Bug System).

Mechanism for disabling signature schemes based on their TLS scope

From OpenJDK 17.0.17 onward, the jdk.tls.disabledAlgorithms security property also accepts suffix values that specify and limit the use of specific algorithms. In this situation, you can specify that a particular algorithm may be used in TLS handshake exchanges only or for signing TLS certificates only.

Each suffix value must consist of the word usage and either HandshakeSignature for TLS handshake exchanges or CertificateSignature for TLS certificates. For example, rsa_pkcs1_sha1 usage HandshakeSignature indicates that the rsa_pkcs1_sha1 algorithm may be used in TLS handshake exchanges only and it cannot be used for signing TLS certificates.

Note

If you do not specify a suffix for a particular algorithm, this algorithm is considered to be fully disabled as in earlier releases.

See JDK-8349583 (JDK Bug System).

"Best-fit" mapping disabled in Windows command prompt

In earlier releases, on Windows platforms, the Java launcher used the American National Standards Institute (ANSI) version of the GetCommandLine() Win32 API call to obtain command-line arguments. In this situation, if the command-line arguments contained Unicode characters that did not exist in the ANSI code page, these arguments were converted to other characters based on the Windows "best fit" mapping. However, this mapping could have introduced unexpected characters and differed between code pages.

From OpenJDK 17.0.17 onward, the JDK reads command-line arguments as Unicode characters and then converts them to the ANSI code page, using the default replacement for any unmappable character. If applications need to use unmappable characters as is, without replacement, ensure that you select UTF-8 in the Windows regional settings.

See JDK-8337506 (JDK Bug System).

Information improvements for container memory usage

From OpenJDK 17.0.17 onward, the JDK provides additional information for containers by also including memory usage details for both the Resident Set Size (RSS) and the cache. These memory usage details are specified in bytes.

This additional information is visible in both of the following locations:

  • The output of the jcmd <PID> VM.info command (where <PID> represents the running JVM)
  • The hs_err file that is generated if the JVM terminates abruptly

See JDK-8313083 (JDK Bug System).

Fix for SunMSCAPI provider to allow processes without elevated permissions to read local computer keystore certificates

In earlier releases, the SunMSCAPI provider required processes to have administrator privileges to access the local computer keystore.

From OpenJDK 17.0.17 onward, the SunMSCAPI provider allows processes without elevated permissions to access the keystore in read-only mode by using the CERT_STORE_MAXIMUM_ALLOWED_FLAG.

See JDK-8313367 (JDK Bug System).

2.2. Deprecated features

The following pre-existing features have been either deprecated or removed in Eclipse Temurin 17.0.17:

AffirmTrust root CA certificates removed

From OpenJDK 17.0.17 onward, the cacerts truststore no longer includes the following AffirmTrust root certificates, which were deactivated in the OpenJDK 17.0.13 release in October 2024:

Certificate 1
  • 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 2
  • 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 3
  • 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 4
  • Alias name: affirmtrustpremiumeccca [jdk]
  • Distinguished name: CN=AffirmTrust Premium ECC, O=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-8361212 (JDK Bug System).

Revised on 2025-10-31 15:49:25 UTC

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