Red Hat build of OpenJDK 17.0.12 发行注记
摘要
前言
Open Java Development Kit (OpenJDK)是 Java Platform, Standard Edition (Java SE)的一个免费的开源实现。红帽构建的 OpenJDK 有四个版本:8u、11u、17u 和 21u。
红帽构建的 OpenJDK 软件包在 Red Hat Enterprise Linux 和 Microsoft Windows 上提供,并作为红帽生态系统目录中的 JDK 和 JRE 提供。
提供有关红帽构建的 OpenJDK 文档的反馈
要报告错误或改进文档,请登录您的红帽 JIRA 帐户并提交问题。如果您没有红帽 JIRA 帐户,系统会提示您创建一个帐户。
流程
- 单击以下链接 来创建 ticket。
- 在 Summary 中输入有关此问题的简单描述。
- 提供有关 描述 中问题或增强功能的详细描述。包括一个 URL,以在文档中发生问题。
- 点 Create 创建并将问题路由到适当的文档团队。
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
第 1 章 红帽构建的 OpenJDK 支持政策
红帽在其产品中支持所选的 Red Hat build of OpenJDK 主版本。为了实现一致性,这些版本与指定为长期支持 (LTS) 的 Oracle JDK 版本类似。
自首次推出该版本时,红帽构建的 OpenJDK 的主版本将最少提供六年。如需更多信息,请参阅 OpenJDK 生命周期和支持政策
RHEL 6 于 2020 年 11 月结束其生命周期。因此,红帽构建的 OpenJDK 不支持 RHEL 6 作为支持的配置。
第 2 章 与上游 OpenJDK 17 的不同
Red Hat build of OpenJDK 在 Red Hat Enterprise Linux 中包含了来自 OpenJDK 上游发行版的许多结构更改。红帽构建的 OpenJDK 版本尝试尽快遵循 Red Hat Enterprise Linux 更新。
以下列表详细介绍了红帽构建的 OpenJDK 17 更改:
- FIPS 支持。Red Hat build of OpenJDK 17 会自动检测 RHEL 是否处于 FIPS 模式,并自动配置红帽构建的 OpenJDK 17 以在该模式下运行。此更改不适用于针对 Microsoft Windows 的红帽构建的 OpenJDK 构建。
- 加密策略支持。Red Hat build of OpenJDK 17 从 RHEL 系统配置获取启用的加密算法和密钥大小限制列表。这些配置组件由传输层安全(TLS)加密协议、证书路径验证和任何签名的 JAR 使用。您可以设置不同的安全配置集来平衡安全性和兼容性。此更改不适用于针对 Microsoft Windows 的红帽构建的 OpenJDK 构建。
-
在 RHEL 上构建 OpenJDK 会动态链接到原生库,如
zlib
用于归档格式支持,libjpeg-turbo
、libpng
和giflib
用于镜像支持。RHEL 还动态链接Harfbuzz
和Freetype
用于字体渲染和管理。此更改不适用于针对 Microsoft Windows 的红帽构建的 OpenJDK 构建。 -
src.zip
文件包含由红帽构建的 OpenJDK 附带的所有 JAR 库的源。 - Red Hat build of OpenJDK on RHEL 使用系统范围的时区数据文件作为时区信息的源。
- RHEL 上的红帽构建的 OpenJDK 使用系统范围的 CA 证书。
- Red Hat build of OpenJDK on Microsoft Windows 包括 RHEL 的最新可用时区数据。
- Red Hat build of OpenJDK on Microsoft Windows 使用 RHEL 的最新可用 CA 证书。
其他资源
第 3 章 对 Windows 构建工件命名规则的计划更改
从 2024 年 10 月开始,红帽计划引入一些作为 Windows Server 平台构建 OpenJDK 版本的一部分分发的文件的命名更改。
这些文件命名更改将影响红帽为 OpenJDK 版本 8、11 和 17 的 JDK、JRE 和 debuginfo
软件包提供的 .zip
归档和 .msi
安装程序。
这个变化的目的是采用一个通用命名惯例,它在红帽支持的所有 OpenJDK 版本中保持一致。红帽构建的 OpenJDK 版本 8、11 和 17 将与红帽构建的 OpenJDK 21 所用命名约定保持一致。这意味着红帽构建的 OpenJDK 21 不需要任何命名更改。
这些计划的更改不会影响任何红帽构建的 OpenJDK 版本的 Linux 可移植构建的文件。
Red Hat build of OpenJDK 17.0.12 是红帽计划对 Windows 工件使用旧命名约定的最后一个版本。以下列表提供了计划命名更改对将来的 OpenJDK 17 版本如何影响每个文件的示例:
JDK 软件包的 MSI 安装程序
-
旧文件名:
java-17-openjdk- <version> .win.x86_64.msi
-
新文件名:
java-17-openjdk- <version> .win.jdk.x86_64.msi
-
旧文件名:
JDK 软件包的
.zip
归档-
旧文件名:
java-17-openjdk- <version> .win.x86_64.zip
-
新文件名:
java-17-openjdk- <version> .win.jdk.x86_64.zip
-
旧文件名:
JRE 软件包的 MSI 安装程序
-
旧文件名:
java-17-openjdk- <version> .jre.win.x86_64.msi
-
新文件名:
java-17-openjdk- <version> .win.jre.x86_64.msi
-
旧文件名:
JRE 软件包的
.zip
归档-
旧文件名:
java-17-openjdk- <version> .jre.win.x86_64.zip
-
新文件名:
java-17-openjdk- <version> .win.jre.x86_64.zip
-
旧文件名:
debuginfo 软件包的
.zip
归档-
旧文件名:
java-17-openjdk- <version> .win.x86_64.debuginfo.zip
-
新文件名:
java-17-openjdk- <version> .win.debuginfo.x86_64.zip
-
旧文件名:
第 4 章 Red Hat build of OpenJDK 功能
最新的 Red Hat build of OpenJDK 17 发行版本可能包括新功能。另外,最新版本可能会增强、弃用或删除来自以前红帽构建的 OpenJDK 17 版本的功能。
有关所有其他更改和安全修复,请参阅 OpenJDK 17.0.12 发行版本。
Red Hat build of OpenJDK 的改进
Red Hat build of OpenJDK 17 为最初在以前 OpenJDK 版本中创建的功能提供改进。
仅 POST
OCSP 请求的回退选项
JDK-8175903 是红帽构建的 OpenJDK 17 中引入的,增加了对将 HTTP GET
方法用于在线证书状态协议(OCSP)请求的支持。此功能为小请求无条件地启用。
Internet Engineering Task Force (IETF) RFC 5019 和 RFC 6960 明确允许,并建议使用 HTTP GET
请求。但是,有些 OCSP 响应器无法在这些类型的请求中正常工作。
Red Hat build of OpenJDK 17.0.12 引入了 JDK 系统属性 com.sun.security.ocsp.useget
。默认情况下,此属性设置为 true
,它会保留对小请求使用 GET
请求的当前行为。如果此属性设置为 false
,则只使用 HTTP POST
请求,无论大小如何。
只有 POST
-only OCSP 请求的这个回退选项是一个非标准功能,如果使用带有 OCSP 响应器的 HTTP GET
请求,则在以后的发行版本中可能会删除它。
请参阅 JDK-8328638 (JDK Bug System)。
DTLS 1.0 默认禁用
OpenJDK 9 引入了对 Datagram Transport Layer Security (DTLS)协议(JEP-219)版本 1.2 的支持。不再建议使用基于 TLS 1.1 的 DTLSv1.0,因为此协议被视为弱且现代标准不安全。在 OpenJDK 17.0.12 中,如果您尝试使用 DTLSv1.0,则 JDK 会默认抛出一个 SSLHandshakeException
。
如果要继续使用 DTLSv1.0,可以通过修改 java.security
. properties
系统属性或从 jdk.tls.disabledAlgorithms
系统属性中删除 DTLSv1.0
。
不建议使用 DTLSv1.0,处于用户自己的风险下。
请参阅 JDK-8256660 (JDK Bug System)。
RPATH
优先于 RUNPATH
用于内部 JDK 二进制文件中的 $ORIGIN
运行时搜索路径
JDK 中的原生可执行文件和库使用嵌入式运行时搜索路径(rpaths)来定位所需的内部 JDK 原生库。在 Linux 系统上,二进制文件可以使用 DT_RPATH
或 DT_RUNPATH
指定这些搜索路径。
-
如果二进制文件使用
DT_RPATH
指定搜索路径,则会在LD_LIBRARY_PATH
环境变量中指定的任何路径 之前 搜索这些路径。 -
如果二进制文件使用
DT_RUNPATH
指定搜索路径,则仅在LD_LIBRARY_PATH
中指定的路径 后 进行搜索。这意味着,使用DT_RUNPATH
可让 JDK 内部库被LD_LIBRARY_PATH
中指定的名称的任何库覆盖,这在安全视角中不可取。
在以前的版本中,使用的运行时搜索路径类型是基于动态链接器的默认搜索路径。在 OpenJDK 17.0.12 中,为确保使用 DT_RPATH
,--disable-new-dtags
选项被明确传递给链接器。
请参阅 JDK-8326891 (JDK Bug System)。
TrimNativeHeapInterval
选项作为产品交换机提供
红帽构建的 OpenJDK 17.0.12 提供了 -XX:TrimNativeHeapInterval=ms
选项作为官方产品切换。此功能增强使 JVM 可以在支持的平台上指定间隔(以毫秒为单位)修剪原生堆。目前,这个增强唯一支持的平台是使用 glibc
的 Linux。
您可以通过设置 TrimNativeHeapInterval=0
来禁用修剪。修剪功能默认为禁用。
请参阅 JDK-8325496 (JDK Bug System)。
-XshowSettings
launcher 选项包含一个 安全
类别
在 OpenJDK 17.0.12 中,-XshowSettings
launcher 选项包含一个安全类别,允许传递以下参数:
参数 | 详情 |
---|---|
or
| 显示所有安全设置并继续。 |
| 显示安全属性并继续。 |
| 显示静态安全提供程序设置并继续。 |
| 显示与 TLS 相关的安全设置并继续。 |
如果应用程序类路径或模块路径中包含第三方安全供应商,且在 java.security
文件中配置,则输出会包括这些第三方安全提供程序。
请参阅 JDK-8281658 (JDK Bug System)。
添加了 GlobalSign R46 和 E46 root 证书
在 OpenJDK 17.0.12 中,cacerts
truststore 包括两个 GlobalSign TLS root 证书:
- 证书 1
- Name: GlobalSign
- 别名名称:globalsignr46
- distinguished name: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE
- 证书 2
- Name: GlobalSign
- 别名名称:globalsigne46
- distinguished name: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
请参阅 JDK-8316138 (JDK Bug System)。
修复了在代码 根扫描
阶段因为不平衡迭代而暂停长时间垃圾回收的修复
垃圾回收的代码 根扫描
阶段查找对编译的代码中的 Java 对象的引用。为加快这个过程,会在包含 Java 堆引用的编译代码的每个区域中维护缓存。
假设一组引用非常小,以前的发行版本使用每个区域的单一线程来迭代这些引用。这种单线程方法引入了一个可扩展性瓶颈,如果特定区域包含大量参考,则性能可能会降低。
在 Red Hat build of OpenJDK 17.0.12 中,会使用多个线程,这有助于删除任何可伸缩瓶颈。
请参阅 JDK-8315503 (JDK Bug System)。
在 Windows 上更改 AWT 无头模式检测的行为
在早期版本中,除非 java.awt.headless
系统属性被设置为 true
,否则在 Windows Server 平台上调用 java.awt.GraphicsEnvironment.isHeadless ()
返回 false
。
从 OpenJDK 17.0.12 开始,除非 java.awt.headless
属性明确设置为 false
,且当前系统上没有检测到有效的 monitor,则调用 java.awt.GraphicsEnvironment.isHeadless ()
会在 Windows Server 平台上返回 true
。可能无法检测到有效的 monitor,例如,如果会话是由服务启动还是 PowerShell 远程启动。
这个行为的变化意味着在这些条件下运行的应用程序(以前预期会在头环境中运行),现在可能会遇到 Abstract Window Toolkit (AWT)操作所引发的非 头例外
错误。
您可以通过将 java.awt.headless
属性设置为 false
来重新恢复旧行为。但是,如果应用程序以 headful 模式运行,且有效的显示不可用,则这些应用程序可能会继续遇到意外问题。
第 5 章 与本发行版本相关的公告
以下公告包括了记录程序错误修复和 CVE 修复:
更新于 2024-07-23