作者：林岚｜OC 技术与安全编辑

OpenJDK 正在讨论 JEP 541，计划从 JDK 27 开始弃用 macOS/x64 移植版，并在未来版本中删除。提案称，随着苹果硬件全面转向 AArch64，Oracle 工程师将停止维护 Intel Mac 版本，以减少持续的测试和适配成本。

一句话结论：Intel Mac 上的 Java 不会在 JDK 27 发布当天突然失效，但官方上游准备停止为这条架构路线兜底，继续运行将越来越依赖旧版 JDK 或社区维护者。

JEP 541 当前状态是 Candidate，即候选提案，尚未集成到正式 JDK。按现有方案，在 macOS/x64 上配置构建时会默认报错，开发者必须显式加入 --enable-deprecated-ports 才能继续，并收到“未来可能删除”的警告。

即使打开开关，项目也不保证该端口能成功构建或正常工作。OpenJDK 仓库的 GitHub Actions 将默认禁用 macOS/x64，以免这条路线上的测试失败阻塞主线开发。文档中的相关功能也会被标记为待删除。

这和“Intel Mac 不能运行 Java”是两回事。现有 JDK、应用和 Rosetta 兼容层仍可能继续使用，第三方发行版也可以自行维护。但缺少上游持续集成后，新垃圾收集器、JIT、系统 API 和安全更新是否在 x64 macOS 上工作，将不再有同等保证。

OpenJDK 给出的替代方案很直接：如果一组可信开发者愿意在提案集成前接管维护，JEP 可以撤回；集成后、正式删除前也可以用后续 JEP 逆转。问题因此不是技术上能不能保留，而是谁愿意长期承担机器、测试和修复成本。

苹果从 2020 年开始转向自研芯片，当前 Mac 产品线已经完成架构迁移。对 Java 上游而言，为数量持续下降的 Intel Mac 保留完整端口，会拖慢主线功能并扩大测试矩阵。林岚认为，JEP 541 是生态生命周期的正常信号，也是仍在使用 Intel Mac 构建链的团队应开始迁移的明确时间表。

关键事实

• 来源：OpenJDK JEP 541、JEP 391
• 当前状态：Candidate，尚未成为正式 JDK 变更
• 计划版本：Oracle 工程师拟从 JDK 27 起停止维护 macOS/x64
• 继续构建：需显式使用 --enable-deprecated-ports，且不保证可用

OC 判断

弃用的含义是维护承诺结束，而不是二进制立即失效。团队现在需要盘点的是构建机、签名流程和本地依赖，而不是等到某个新版 JDK 无法编译时再处理。

为什么重要

• 对开发者：仍使用 Intel Mac 的 Java 项目应测试 Apple Silicon 构建和依赖兼容性。
• 对企业：CI、代码签名和桌面客户端发布链需要制定硬件迁移计划。
• 对用户：旧应用短期仍能运行，但未来安全更新和新版本支持可能减少。

参考来源

• OpenJDK：JEP 541 Deprecate the macOS/x64 Port
• OpenJDK：JEP 391 macOS/AArch64 Port