Chapter 3. 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 11 release of Eclipse Temurin includes, see OpenJDK 11.0.27 Released.

New features and enhancements

Eclipse Temurin 11.0.27 includes the following new features and enhancements.

Warnings from jarsigner tool about removed file entries

In earlier OpenJDK releases, when a file was removed from a signed JAR file but the file signature was still present, the jarsigner tool did not detect this situation.

In OpenJDK 11.0.27, you can use the jarsigner ‑verify command to check that every signature has a matching file entry. If any mismatch exists, this command prints a warning. To display the names of any mismatched entries, add the ‑verbose option to the command.

See JDK-8309841 (JDK Bug System).

Distrust of TLS server certificates issued after 15 April 2025 and anchored by Camerfirma root CAs

In accordance with similar plans that Google, Mozilla, Apple, and Microsoft recently announced, OpenJDK 11.0.27 distrusts TLS certificates that are issued after 15 April 2025 and anchored by Camerfirma root certificates.

OpenJDK will continue to trust certificates that are issued on or before 15 April 2025 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 2025-04-15 and anchored by a distrusted legacy Camerfirma root CA: CN=Chambers of Commerce Root -
2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU

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 organisation that is responsible for managing the certificate.

If you want to continue using TLS server certificates that are anchored by Camerfirma root certificates, you can remove CAMERFIRMA_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 Camerfirma root certificates that OpenJDK includes:

Certificate 1
  • Alias name: camerfirmachamberscommerceca [jdk]
  • Distinguished name: CN=Chambers of Commerce Root OU=http://www.chambersign.org O=AC Camerfirma SA CIF A82743287 C=EU
  • SHA256: 0C:25:8A:12:A5:67:4A:EF:25:F2:8B:A7:DC:FA:EC:EE:A3:48:E5:41:E6:F5:CC:4E:E6:3B:71:B3:61:60:6A:C3
Certificate 2
  • Alias name: camerfirmachambersca [jdk]
  • Distinguished name: CN=Chambers of Commerce Root - 2008 O=AC Camerfirma S.A. SERIALNUMBER=A82743287 L=Madrid (see current address at www.camerfirma.com/address) C=EU
  • SHA256: 06:3E:4A:FA:C4:91:DF:D3:32:F3:08:9B:85:42:E9:46:17:D8:93:D7:FE:94:4E:10:A7:93:7E:E2:9D:96:93:C0
Certificate 3
  • Alias name: camerfirmachambersignca [jdk]
  • Distinguished name: CN=Global Chambersign Root - 2008 O=AC Camerfirma S.A. SERIALNUMBER=A82743287 L=Madrid (see current address at www.camerfirma.com/address) C=EU
  • SHA256: 13:63:35:43:93:34:A7:69:80:16:A0:D3:24:DE:72:28:4E:07:9D:7B:52:20:BB:8F:BD:74:78:16:EE:BE:BA:CA

See JDK-8346587 (JDK Bug System).

Fix for invokedynamic string concatenation changing order of operations

The Indify String Concatenation feature that was added in OpenJDK 9 through JEP-280 introduced a regression in the order in which string concatenation expressions are evaluated. The Java Language Specification requires that operands are fully evaluated in left-to-right order. However, with the introduction of invokedynamic (indy) call generation by the javac compiler for evaluating string concatenation expressions, all operands were evaluated in order but not converted to strings. In this situation, each operand was converted to a string only later.

For example, consider the following code, where the third argument of the concatenation has the side effect of altering the value of builder to "goodbye":

StringBuilder builder = new StringBuilder("good");
return "" + builder + builder.append("bye");

Based on the preceding example, in earlier releases, the Indify String Concatenation feature did not convert the second argument to a string until after the builder.append method altered the StringBuilder object. In this situation, the concatenation incorrectly became "" + "goodbye" + "goodbye", which produced "goodbyegoodbye" as the output.

In OpenJDK 11.0.27, string concatenation evaluates and eagerly converts each argument to a string in left-to-right order. In this situation, the concatenation correctly becomes "" + "good" + "goodbye", which produces "goodgoodbye" as the output.

Note

The resolution of this issue has the same effect as using a version of the javac compiler that was available before OpenJDK 9 or running javac with the -XDstringConcat=inline command-line option.

See JDK-8273914 (JDK Bug System).

Revised on 2025-04-29 11:37:50 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, Inc.