OpenJDK 提出了编号 JEP 541 的提案，建议从 JDK 27 开始弃用 macOS/x64 移植版本。提案由 Mikael Vidstedt 主导，2026 年 6 月 5 日创建，目前状态是 Candidate（候选），还没有正式通过。

弃用不等于删除。JDK 27 发布后，已经装好的 Java 环境不会突然失效。真正变的是维护责任：Oracle 工程师退出，默认持续集成关闭，代码本身还留在仓库里。

先动的是构建流程，不是已发布版本

按提案描述，普通用户执行 ./configure 编译 macOS/x64 版本会直接报错退出，代码是 1。想强行编译，得加上新选项 --enable-deprecated-ports，报错会降级成警告，流程能走完。但官方不保证这个版本还能编译成功，更不保证编译出来能正常运行。

构建方式现状（弃用前）JDK 27 弃用后
默认执行 ./configure正常编译报错退出，代码 1
加 --enable-deprecated-ports不需要报错降级为警告，可继续构建，但不保证成功或能正常运行
GitHub Actions 持续集成覆盖 macOS/x64默认关闭

JDK 仓库文档也会把 macOS/x64 标注为"计划移除"。一旦默认构建和 CI 保障都撤了，这条移植线出问题不会有人第一时间发现和修。

弃用后的构建实测 默认执行 configure checking compilation type... error: 弃用移植，可能被移除 configure exiting, 退出码 1 加 --enable-deprecated-ports WARNING: 弃用移植提示 继续完成配置与构建 仅关闭报错，不代表恢复维护 两种路径都不保证能构建成功或正常运行

JEP 541 只针对 JDK 27 之后的官方构建，不涉及已经发布的版本。正在用的 JDK 21、25 等 LTS 二进制不会因为这份提案突然失效。但官方后续会维护到什么程度、更早的更新流是否跟进同样的弃用逻辑，提案文本里没有交代，这一点目前看不清。

两类人现在就该做决定

受影响的不是所有 Java 用户，是两类具体的人：还在英特尔 Mac 上做开发和跑 CI 的团队，以及负责打包发行 macOS x64 二进制、做兼容性测试的厂商。

受影响对象现状可以做的动作
用英特尔 Mac 做 Java 开发 / CI 的团队暂时能用，但官方维护和 CI 保障已经开始退出评估换 Apple Silicon 设备的时间窗，不必等到 JDK 27 正式发布才动手
发行 macOS x64 二进制、跑兼容性测试的厂商JEP 541 还是候选状态，正式整合前有接盘窗口现在决定要不要接手维护；没人接盘，弃用大概率走向正式移除

提案里留了退路：正式整合前，如果有可信开发者明确表示愿意接手维护，JEP 541 可以直接撤回。整合之后、正式移除之前才有人站出来，也能靠后续 JEP 把决定反转回去。这套机制不是新花样，OpenJDK 处理过去其他平台移植版本弃用时用的就是它。

苹果六年前转 Arm，OpenJDK 现在收尾

Oracle 给出的理由是维护成本：苹果硬件早就转向 AArch64，继续维护 x64 移植线越来越不划算。苹果发布首款 M1 芯片是在 2020 年，距今六年，Mac 产品线基本完成了向 Arm 的整体切换。

这更像是 OpenJDK 跟着硬件厂商的节奏走完最后一步，而不是自己主动收缩。材料里没有提到 Oracle 财务或业务层面的压力，把这次弃用读成"财务吃紧"是过度解读。

真正的变量只有一个：有没有人愿意接盘。JEP 541 还是候选状态，没有确定的正式移除时间。等不到接盘的开发者，这条移植线大概率会走完弃用、观察、移除这三步。