关于 JDK 27 和 JDK 28，我们目前都知道些什么
甲骨文公司 Java 平台组首席架构师 Mark Reinhold 宣布，作为自 JDK 25 发布以来的第二个非 LTS 版本，JDK 27 现在已经进入了首个发布候选版阶段。主干源代码库（已于 2026 年 6 月初分叉至 JDK 稳定版本库，即 Rampdown 第一阶段）定义了 JDK 27 的功能集。严重缺陷（如回归问题或严重的功能问题）可能会得到修复，但必须通过修复请求（Fix-Request）流程进行审批。根据发布计划，JDK 27 将于 2026 年 9 月 15 日正式发布。
最终确定的九项新特性（以 JEP 形式呈现）可以分为四大类：核心 Java 库、HotSpot、安全库和 Java 语言规范。
其中有三项新特性归类为核心 Java 库：
其中有三项新特性归类为 HotSpot：
JEP 523：在所有环境中将 G1 设为默认垃圾回收器
JEP 534：默认采用紧凑对象头
JEP 536：JFR 进程内数据屏蔽
其中有两项新特性归类为安全库：
JEP 527：TLS 1.3 后量子混合密钥交换
JEP 538：加密对象 PEM 编码（第三个预览版）
最后，其中一项新特性归类于 Java 语言规范：
JEP 532：模式、instanceof 和 switch 中的基本类型（第五个预览版）
我们将探讨其中的部分新特性，并说明它们隶属于哪些主要 Java 项目：Amber、 Loom、 Panama、 Valhalla 和 Leyden。这些项目旨在孵化一系列组件，并最终通过筛选合并流程将其纳入 JDK。
Amber 项目
在 JDK 23 至 JDK 26 期间完成了四轮预览后，JEP 532（模式、instanceof 和 switch 中的基本类型第五个预览版）提出进行第五轮预览，其中包含两项变更。该特性通过允许在所有模式上下文中使用基本类型增强了模式匹配功能，并扩展 instanceof 和 switch 结构，使它们支持所有的基本类型。变更内容包括：完善了无条件准确性定义；在 switch 结构中应用了更严格的支配性检查。
Loom 项目
JEP 533（结构化并发第七个预览版）提出进行第七轮预览，其中包含一些细微的调整。此前，该项目已经在 JDK 21 至 JDK 26 期间进行了六轮预览，并在 JDK 19 至 JDK 20 期间进行了两轮孵化。该功能通过引入结构化并发来简化并发编程，旨在“将运行在不同线程中的相关任务组视为单个工作单元，从而简化错误处理和取消操作，提高可靠性，并增强可观察性。”
Panama 项目
JEP 537（向量 API 第十二轮孵化）提议启动第十二轮孵化。此前，该功能已经经历十一轮孵化（从 JDK 16 到 JDK 26），而且其实现自 JDK 25 以来未发生实质性变化。该功能引入了一套 API，用于“表达向量计算，而这些计算可以在运行时可靠地编译为受支持 CPU 架构上的最优向量指令，从而实现优于等效标量计算的性能。” 向量 API 将继续处于孵化阶段，直至 Valhalla 项目中的必要功能作为预览功能发布。届时，向量 API 团队将调整向量 API 及其实现以支持这些功能，并将向量 API 从“孵化”阶段提升至“预览”阶段。
安全库
在 JDK 25 和 JDK 26 中经历了两轮预览后，JEP 538（加密对象 PEM 编码第三个预览版）提出进行第三轮预览。该功能提供了“一个 API，用于将表示加密密钥、证书和证书撤销列表的对象编码为广泛使用的增强隐私邮件（PEM）传输格式，并从该格式解码回对象”。该 JEP 将支持 PEM 文本与 PKCS #8 和 X.509 二进制格式的加密对象之间的相互转换。变更内容包括：将 PEM 记录类重新分类为普通类，以便提供一个构造函数，使其可以接受字节数组中 Base64 编码内容；将 DEREncodable 接口重命名为 BinaryEncodable，以便更准确地描述 PEM 文本中存储的二进制数据。
HotSpot
JEP 536（JFR 进程内数据屏蔽）提议增强 JDK Flight Recorder（JFR），使其在 JFR 完成记录之前对敏感信息进行屏蔽。这些信息可能包括命令行参数、环境变量的初始值以及系统属性。
JEP 534（默认采用紧凑对象头）提议将 JEP 519（紧凑对象头）（已随 JDK 25 发布）设为 HotSpot JVM 中的默认对象头布局。要了解有关紧凑对象头的更多详情，可以参阅这篇 InfoQ 新闻报道。
JEP 523（在所有环境中将 G1 设为默认垃圾回收器）提议将“垃圾优先”垃圾回收器（G1 GC）设为“所有环境中的默认选项，而不仅仅是服务器环境”。如果命令行中未指定垃圾回收器，则 HotSpot JVM 将始终选择 G1 GC。
JDK 28
JDK 28 计划于 2027 年 3 月发布 GA 版本，届时将包含六项 JEP（其中五项为 Targeted 状态，一项为 Proposed to Target 状态）。我们还将评估哪些 JEP 候选方案和草案有纳入 JDK 28 的潜力，特别是那些已提交或处于增量预览阶段的提案。
JEP 541（废弃 macOS/x64 移植版以备移除）已确定为 JDK 28 的目标。该 JEP 提议废弃 macOS/x64 移植版本，因为苹果公司已经不再支持该架构。与 JEP 449（废弃 Windows 32 位 x86 移植版以备移除）类似，此举旨在通过在未来版本中移除该移植版本来节省维护成本。
JEP 540（简单 JSON API 第一个孵化版））已确定为 JDK 28 的目标。该 JEP 定义了一个简单的标准 API，用于解析和生成 JSON 文档，无需依赖外部库。该功能实现了 RFC 8259（JavaScript 对象表示法（JSON）数据交换格式）。该提案取代了 JEP 198（轻量级 JSON API），后者现已关闭并撤回。
JEP 539（JVM 中严格字段初始化预览版）已确定为 JDK 28 的目标。该 JEP 在 Java 虚拟机中引入了严格初始化字段，这些字段在被读取之前必须先进行初始化。因此，永远不会观察到诸如 0 或 null 之类的默认值。该功能可供生成类文件的编译器使用。
JEP 535（Shenandoah 垃圾回收器：默认启用分代模式）已确定为 JDK 28 的目标。该 JEP 提议将 Shenandoah 垃圾回收器默认设置为分代模式。非分代模式将被标记为已弃用，并计划在未来版本中移除。
JEP 401（值对象预览版）已确定为 JDK 28 的目标。该 JEP 此前名为（对象类与值预览版），提议通过值对象来增强语言功能。值对象被定义为：仅包含 final 字段；不具有身份标识；对象之间仅能通过各自字段的值来区分。要了解有关 JEP 401 的更多详情，请参阅这篇 InfoQ 新闻报道。
JEP 542（加密对象 PEM 编码）已被提议作为 JDK 28 的目标。在 JDK 25 至 JDK 27 期间完成三轮预览后，该 JEP 提议将该功能最终定稿。该功能提供“一个 API，用于将表示加密密钥、证书和证书撤销列表的对象编码为广泛使用的增强隐私邮件（PEM）传输格式，并从该格式解码回对象”。该 JEP 将支持 PEM 文本与 PKCS #8 和 X.509 二进制格式加密对象之间的相互转换。变更内容包括：将 PEM 记录类重新分类为普通类，以便提供一个构造函数，可以接受字节数组中的 Base64 编码内容；将 DEREncodable 接口重命名为 BinaryEncodable，以便更准确地描述 PEM 文本中存储的二进制数据。
在经历了三轮预览（分别将于即将推出的 JDK 27、 JDK 26 以及 JDK 25 版本中发布）后，JEP 草案 8389764（惰性常量第四个预览版）提出进行第四轮预览，内容未作任何更改。该功能原名为“稳定值和计算常量”。它引入了“计算常量”的概念，其定义为最多初始化一次的不可变值容器。这使其既具备 final 字段的性能和安全优势，又在初始化时机方面提供了更大的灵活性。随着 JDK 26 的发布，其名称从“稳定值”更改为“惰性常量”，从而更准确地体现高级用例的意图。
JEP 草案 8329758（利用 ZGC 加快启动和预热速度）提议增强 Z 垃圾回收器，使其能够更高效地根据应用程序的需求分配内存，并通过仅创建一个较小的初始堆来减少操作系统开销，从而将启动时间降至最低。
请注意，JEP 草案内容随时可能发生变化。我们预计 Oracle 很快会为 JDK 28 提出更多的 JEP 提案。