第 4 章 Red Hat build of OpenJDK 功能
最新的 Red Hat build of OpenJDK 11 发行版本可能包括新功能。另外,最新版本可能会增强、弃用或删除来自以前红帽构建的 OpenJDK 11 版本的功能。
有关所有其他更改和安全修复,请参阅 OpenJDK 11.0.27 发行版本。
Red Hat build of OpenJDK 的新功能和功能增强
请参阅以下发行注记以了解红帽构建的 OpenJDK 11.0.27 提供的新功能和功能增强:
jarsigner 工具中关于删除的文件条目的警告
在以前的红帽构建的 OpenJDK 版本中,当从签名的 JAR 文件中删除文件时,但文件签名仍然存在,jarsigner 工具不会检测到这种情况。
在 Red Hat build of OpenJDK 11.0.27 中,您可以使用 jarsigner -verify 命令检查每个签名是否有匹配的文件条目。如果存在不匹配,这个命令会打印警告信息。要显示任何不匹配条目的名称,请在命令中添加 -verbose 选项。
请参阅 JDK-8309841 (JDK Bug System)。
在 2025 年 4 月 15 日后发布的 TLS 服务器证书的不信任,由 Camerfirma 根 CA 发布
根据 Google、Mozilla、Apple 和 Microsoft 最近宣布的类似计划,红帽构建 OpenJDK 11.0.27 不信任 TLS 证书,这些证书在 2025 年 4 月 15 日后发布,并由 Camerfirma root 证书发布。
Red Hat build of OpenJDK 将继续信任在 2025 年 4 月 15 日发布的证书,直到这些证书过期。
如果服务器的证书链由受影响的证书决定,则任何尝试协商 TLS 会话现在都会失败,但表明信任锚不被信任。例如:
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
您可以使用以下 keytool 命令检查此更改是否影响 JDK 密钥存储中的证书:
keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>
如果此更改会影响链中的任何证书,请更新此证书或联系负责管理证书的机构。
如果要继续使用 Camerfirma root 证书实现的 TLS 服务器证书,您可以通过修改 java.security. properties 系统属性或从 jdk.security.caDistrustPolicies 安全属性中删除 CAMERFIRMA_TLS。
继续使用不信任的 TLS 服务器证书的风险自有风险。
这些限制适用于红帽构建的 OpenJDK 构建的以下 Camerfirma 根证书,其中包括:
- 证书 1
- 别名名称: camerfirmachambers Businessca [jdk]
- 区分名称: 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
- 证书 2
- 别名名称: camerfirmachambersca [jdk]
- 区分名称:CCN=Chambers of Commerce Root - 2008 O=AC Camerfirma S.A.SERIALNUMBER=A82743287 L=Madrid (请参阅 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
- 证书 3
- 别名名称: camerfirmachambersignca [jdk]
- 可分辨名称:CN=Global Chambersign Root - 2008 O=AC Camerfirma S.A.SERIALNUMBER=A82743287 L=Madrid (请参阅 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
请参阅 JDK-8346587 (JDK Bug System)。
修复 调用dynamic 字符串串联更改操作顺序
OpenJDK 9 到 JEP-280 添加的 Indify String Concatenation 功能按字符串串联表达式被评估的顺序引入了一个回归。Java 语言规范 要求以左到右顺序完全评估操作对象。但是,引入 invokedynamic (indy)调用由 javac 编译器生成,用于评估字符串串联表达式,所有操作对象都会按顺序评估,但不会转换为字符串。在这种情况下,每个操作对象仅在稍后转换为字符串。
例如,请考虑以下代码,其中串联的第三个参数具有将 构建器 的值更改为 "goodbye" 的副作用:
StringBuilder builder = new StringBuilder("good");
return "" + builder + builder.append("bye");
根据前面的例子,在早期版本中,Indify String Concatenation 功能不会将第二个参数转换为字符串,直到 builder.append 方法更改了 StringBuilder 对象。在这种情况下,串联会错误地成为 "" + "goodbye" + "goodbye",这会生成 "goodegoodbye" 作为输出。
在 OpenJDK 11.0.27 的红帽构建中,字符串串联评估和立即将每个参数转换为字符串(按左到右的顺序)。在这种情况下,串联可以正确地变为 "" + "good" + "goode",这会生成 "goodbye" 作为输出。
这个问题的解决方法与使用 OpenJDK 9 之前提供的 javac 编译器版本相同,或使用 -XDstringConcat=inline 命令行选项运行 javac。