JDK 28 已将 JEP 541（Deprecate the macOS/x64 Port for Removal）定为 target。按该 JEP 描述，在 macOS/x64 上执行 bash ./configure 会默认以 error 退出，只有加上 --enable-deprecated-ports 才能继续，且不保证该端口仍可编译、可运行。对仍使用 Intel Mac 或 macos-x64 CI 镜像的团队来说，这意味着要尽快规划迁到 aarch64，或确认自己的 JDK 发行版还能从哪里拿到 x64 构建。
这条新闻落在哪条时间线上
2026 年 9 月 29 日，inside.java 宣布 JEP 541 已 targeted 到 JDK 28。OpenJDK 页面上该 JEP 的 Status 为 Completed、Release 为 28，Owner 为 Mikael Vidstedt，讨论区挂在 hotspot-dev。
若把这条消息读成「今天突然砍掉 macOS Intel 支持」，时间线会对不齐。JEP 的 Motivation 写得很直白：Apple 已把硬件产品转到 AArch64，并在逐步收掉对 x64 的支持；Oracle 工程师因此从 JDK 27 起就不再维护 macOS/x64 端口，继续扛这个端口的成本很高。JEP 541 做的是正式「弃用并拟在未来版本移除」：在构建系统与文档里标红，并让默认 configure 失败，避免无人维护的端口继续默默进主线。
再往前半个月，Eclipse Adoptium 已在 2026 年 9 月 2 日宣布：Temurin JDK 27 将不再为 macOS x64 构建或发布。Adoptium 给出的理由是硬件难买难养，以及上游端口将在 JDK 28 弃用；他们选择提前一个大版本停掉 Temurin 的 macos-x64 产物。公告同时说明：更早版本的 Temurin macOS x64 发布不受影响，JDK 27 起请改用 macOS aarch64 构建。社区反馈入口挂在 Adoptium 跟踪 issue（见其新闻页链接）。
把三件事串起来看：Oracle 自 JDK 27 停维护该端口 → Temurin 27 已不出 macos-x64 → JDK 28 以 JEP 541 正式弃用。读者侧的压力来自这条链条，而不是单日公告。若你们内部 changelog 还写着「等 JDK 28 再说」，建议把 Temurin 27 那一刀也写进去，否则升级窗口会被算短。
构建行为会怎样变
JEP 541 给出的默认 configure 失败示例如下（摘自 OpenJDK JEP 正文）：
$ bash ./configure
...
checking compilation type... native
configure: error: The macOS/x64 port is deprecated and may be removed in a future release. Use --enable-deprecated-ports to suppress this error.
configure exiting with result code 1加上新选项后可以压掉 error，但会留下 WARNING：
$ bash ./configure --enable-deprecated-ports
...
checking compilation type... native
configure: WARNING: The macOS/x64 port is deprecated and may be removed in a future release.
...JEP 明确写了：即使开了 --enable-deprecated-ports，也不保证该端口还能编过，更不保证编出来能跑。换言之，这是一条「知情后自担风险」的逃生口，官方并未承诺继续支持。依赖「默认可编」的脚本、镜像或 GitHub Actions workflow，在拉到合入该 JEP 的源码后会直接挂在 configure 阶段。
同文还约定：为了不拖住主线开发，JDK 仓库的 GitHub Actions 里会默认关掉 macOS/x64；相关文档也会标注该端口及端口相关特性「deprecated for removal」。这些都是给构建农场和发行版维护者看的信号。业务项目若还在 macos-x64 runner 上编 OpenJDK 自己，迟早会撞上默认失败；若只是下载预编译 JDK 跑应用，影响路径不同，见下一节。
关于「拟移除」的时间点：JEP 541 本身只完成弃用与构建门禁，并未在正文里给出具体的移除版本号。后续真正删代码，通常还要另开移除类 JEP 或同等流程。本文不以猜测版本号代替官方计划。
对应用团队意味着什么
多数人并不自己 ./configure 编 OpenJDK，更关心的是能不能继续下载、能不能继续在 CI 里跑 macos-x64 JDK。
若机器或 CI 仍是 Intel Mac：
应用跑在已发布的 JDK 21 / 25 等 LTS（或 Temurin 更早版本）上时，本文所述的 JEP 541 构建开关不会立刻改你手里的二进制；Adoptium 也写明既有更早版本的 macOS x64 发布暂不受影响。真正要盯的是：你计划升到 JDK 27 / 28 时，发行版还发不发 macos-x64。
Temurin 路线上，JDK 27 起已明确没有 macOS x64。继续跟 Temurin 主线，实质选项是换 Apple Silicon 机器或 runner，或在 Intel 上改用其他仍提供该平台的发行版。是否提供、提供到哪一版，需以各发行商公告为准；本文未逐一核验 Oracle、Azul、Amazon Corretto、Microsoft Build of OpenJDK 等在 27+ 的 macos-x64 矩阵。
若你们自己从源码编 OpenJDK，并在 macos-x64 上跑 configure：JDK 28 对应源码合入 JEP 541 后，默认会失败，必须显式 --enable-deprecated-ports，且没有「编得过、跑得稳」的保证。把该 flag 写进 Dockerfile 或 CI 缓存键时，建议同时记下「端口已弃用」的告警，避免后人以为这是常态开关。
CI 侧常见动作是：把 macos-latest 与自托管 Intel runner 上的 JDK 矩阵拆清楚，确认哪些 job 真正依赖 x64 指令集或 x64 专用 native 库；能迁 aarch64 的尽早迁。Apple Silicon 上的 macOS aarch64 JDK 才是上游与主流发行版继续投入的方向。若测试套件里还有「必须在 x64 上复现」的历史 bug，单独保留一条有退出日期的 job，比整条流水线卡死在弃用端口上更可控。
JEP 也留了制度上的退路：若有一组可信开发者明确承诺继续维护该端口，在 JEP 合入前可以撤回；合入后、真正移除前，也可以用后续 JEP 撤销弃用。这是港口弃用类 JEP 的惯例表述；在公开承诺出现之前，不能当作已有人接手。在有公开承诺之前，规划应按「端口会进一步收缩」来做。
写进发布说明时建议怎么表述
对内沟通建议写成两句可核对的事实，避免夸大成「macOS 上的 Java 没了」：
- OpenJDK 在 JDK 28 以 JEP 541 弃用 macOS/x64 端口并拟移除；默认 configure 失败，需
--enable-deprecated-ports，且不保证可编可跑。 - 维护与发行侧更早已经收口：Oracle 自 JDK 27 停维护该端口；Temurin 自 JDK 27 不再发布 macOS x64。
行动项按角色分开。桌面开发：确认本机是 Intel 还是 Apple Silicon，Intel 机器上跟 JDK 27+ 时优先核对发行版平台列表。CI：把 macos-x64 从必跑矩阵降为可选并设退出日期，新 job 默认 aarch64。发行或镜像维护者：确认 27+ 是否还需要自建 x64，以及硬件与测试资源是否够撑完你们承诺的支持窗口。未计划自建 OpenJDK 的业务团队，优先核对「下一个要升的 JDK 大版本，手头发行版是否还提供 macos-x64」，而不是先改 configure 参数。
和「只跑应用」的边界
JEP 541 改的是 OpenJDK 源码树里 macOS/x64 端口的构建默认策略与文档标注，直接冲击面是自建 OpenJDK、发行版维护与上游 CI。业务应用若只用发行商提供的预编译 JDK，关键路径是「发行商是否还继续产出 macos-x64」，而不是本机有没有敲 --enable-deprecated-ports。
因此排期时建议按依赖分层：先盘点生产与 CI 实际使用的发行版与大版本；再标出仍绑定 Intel Mac 的开发机与 runner；最后才处理自建 JDK 脚本里的 configure 参数。分层之后，很多人会发现自己根本碰不到 JEP 示例里的报错，但仍然会在升到 Temurin 27 或同等策略的发行版时，突然发现下载页没有 macos-x64。把 Adoptium 9 月 2 日公告和 inside.java 9 月 29 日 target 公告放在同一份变更说明里，可以减少「怎么昨天还能下、今天就没了」的误解。
硬件侧也值得写一句：Adoptium 强调 Intel Mac 越来越难采购与维护，质量门槛撑不住。即便某个团队短期还能从别处拿到 x64 构建，测试机与构建机的可得性也会继续变差。把迁移窗口绑在「还能买到机器」而不是「还能下到包」，往往更贴近真实约束。
一起交流
分享你的思考，让讨论更进一步。