一、决策背景：JEP 8386091 与时间线

1.1 JEP 提案核心内容

2026 年 6 月 5 日，Oracle JVM 高级总监 Mikael Vidstedt 提交了 JEP draft 8386091: Deprecate the macOS/x64 Port for Removal，目标状态为 Submitted [1]。该提案的核心内容如下：

  • Owner: Mikael Vidstedt（Oracle JVM 高级总监）
  • Scope: Implementation
  • Status: Submitted（草稿阶段，截至 2026 年 7 月仍为 draft）
  • Discussion: hotspot-dev@openjdk.org

提案明确提出：Apple 已将硬件平台迁移至 AArch64，正在逐步淘汰对 x64 的支持。因此 Oracle 工程师将从 JDK 27 起停止维护 macOS/x64 端口。维护该端口是一项相当庞大的工程投入，且目前没有明确的长线维护承诺方 [1]。

1.2 时间线梳理

时间节点 事件
2020 年 6 月 Apple 在 WWDC 宣布 Mac 将从 Intel 过渡到自研 Apple Silicon
2020 年 11 月 首批 Apple Silicon Mac（M1）发布
2021 年 3 月 JDK 16 提供 macOS/AArch64 端口早期技术预览（JEP 391）[3]
2021 年 9 月 JDK 17 LTS 首个提供生产级 macOS/AArch64 支持 [4]
2023 年 6 月 Mac Pro 搭载 M2 Ultra 发布，标志 Intel Mac 全面停产 [5]
2025 年 6 月 Apple 宣布 macOS 26 "Tahoe" 为最后一版支持 Intel Mac 的 macOS [6]
2026 年 6 月 5 日 JEP 8386091 提交，提议从 JDK 27 起废弃 macOS/x64 端口 [1]
2026 年 6 月下旬 Oracle JVM 团队提交 Pull Request 实施废弃变更 [2]
2026 年 7 月 JDK 27 Early Access Build 30 发布 [7]
2026 年 9 月 JDK 27 GA 预计发布（届时 macOS/x64 官方构建终止）
2027 年 9 月 JDK 25 LTS 延伸支持结束（Intel Mac 用户最后的安全更新窗口）

1.3 构建系统的变更

根据 JEP 提案，JDK 27 的构建系统将发生以下变更 [1]：

默认行为（失败）：

$ bash ./configure
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

显式启用（警告但可编译，不保证功能正确）：

$ bash ./configure --enable-deprecated-ports
configure: WARNING: The macOS/x64 port is deprecated and may be
removed in a future release.

此外，macOS/x64 将在 OpenJDK 的 GitHub Actions CI 中默认禁用，不再阻塞主线开发 [1]。Oracle 明确声明：即使通过 flag 强制编译，也不保证该端口能够成功构建或正常运行 [1]。

二、Java 在 macOS 上的历史演进

Java 在 macOS 上的支持历程，是一部平台归属权不断易手的编年史。理解这段历史，才能深刻理解为何"放弃 Intel Mac"并非一个突兀的决定。

2.1 macOS 支持历史表

时间段 维护方 架构 关键里程碑
2003–2010 Apple PowerPC → x86_64 Apple 自行维护 Java 6（JVM 整合于 OS X）
2010–2014 Oracle x86_64 Oracle 接管 Java SE，停止 macOS 特定构建
2014–2017 Oracle + 社区 x86_64 OpenJDK 社区逐步建立 macOS 构建能力
2017–2020 OpenJDK 社区 x86_64 AdoptOpenJDK（现 Adoptium）等发行版填补空白
2020–2021 OpenJDK + Oracle x86_64 + AArch64 Apple Silicon 发布；JEP 391 启动 AArch64 移植 [3]
2021–2024 多发行版 AArch64 为主，x86_64 兼容 JDK 17 LTS 原生 AArch64 生产就绪 [4]
2025–2026 Oracle AArch64 Apple macOS 26 "Tahoe" 终止 Intel 支持 [6]；JEP 8386091 提交 [1]
2026 年 9 月起 社区（可能） 仅 AArch64 JDK 27 GA，macOS/x64 端口废弃

2.2 关键转折点

Apple 退出 Java 维护（2010 年）

Apple 在 2010 年宣布不再为 Mac 维护 Java，将 Java SE 的 macOS 支持移交给 Oracle。这一决定在当时引发巨大争议，因为 Apple 的 JVM 实现（基于 HotSpot）在 macOS 上有着良好的集成度和性能。Oracle 接手后，macOS 版本一度滞后于 Windows 和 Linux，催生了 AdoptOpenJDK 等第三方发行版。

Apple Silicon 移植（JEP 391, 2021 年）

2021 年 3 月发布的 JDK 16 包含了 macOS/AArch64 端口的早期技术预览（JEP 391）。该 JEP 由 Oracle 和社区共同推动，复用了已有的 Linux/AArch64 代码（JEP 237），并针对 macOS 的 ABI 差异进行了适配 [3]。

JEP 391 的摘要中明确指出：

"Although it will be possible to run a macOS/x64 build of the JDK on AArch64-based systems via macOS's built-in Rosetta 2 translator, the translation will almost certainly introduce a significant performance penalty." [3]

这一判断为后续完全废弃 x64 端口埋下了伏笔。

三、技术原因深度分析

3.1 Apple Silicon 过渡已完成

Apple 的硬件迁移计划从 2020 年启动到 2023 年完成，历时仅三年：

  • 2020 年 11 月: MacBook Air、MacBook Pro 13"、Mac mini 首发 M1
  • 2021 年: iMac (M1)、MacBook Pro 14"/16" (M1 Pro/Max)
  • 2022 年: MacBook Air (M2)、Mac Studio (M1 Max/Ultra)、MacBook Pro 13" (M2)
  • 2023 年 6 月: Mac Pro (M2 Ultra) 发布——最后一款 Intel Mac 正式停产 [5]

截至 2026 年，Apple Silicon Mac 的市场占有率已接近饱和。Apple 自身也在 2025 年 6 月宣布 macOS 26 "Tahoe" 将是最后一版支持 Intel Mac 的 macOS，从 macOS 27 "Golden Gate" 开始将仅支持 Apple Silicon [6]。

3.2 Rosetta 2 的技术限制

Rosetta 2 是 Apple 提供的动态二进制翻译层，允许 x86_64 应用在 AArch64 系统上运行。然而，对于 JVM 这类运行时环境，Rosetta 2 存在根本性的性能瓶颈：

翻译层级叠加问题：

Java 源码 → javac 字节码 → HotSpot JIT 编译为 x86_64 机器码 → Rosetta 2 再翻译为 AArch64 指令

这意味着 HotSpot 的 C2 JIT 编译器产出的 x86_64 优化代码需要经过 Rosetta 2 的二次翻译才能执行，导致：

  • JIT 编译的代码缓存（code cache）中的机器码被翻译后丧失了原始的寄存器分配和指令调度优势
  • 动态反优化（deoptimization）和运行时代码替换（on-stack replacement）路径的翻译延迟
  • 综合性能损耗约 10%–30% [8]

指令集不支持问题：

Rosetta 2 不支持 AVX-512 指令集 [9]。虽然 JVM 通常不会直接使用 AVX-512，但未来的 HotSpot 优化（如向量 API 的 SIMD 加速路径）如果依赖 AVX-512，将在 Rosetta 2 环境下完全失效。

JIT 与翻译器的交互冲突：

JVM 的 JIT 编译器在运行时会频繁地生成和替换机器码（interpreted → C1 compiled → C2 compiled）。Rosetta 2 的 AOT（Ahead-of-Time）翻译和动态翻译机制对这种高频代码替换的适配并不理想，可能导致：

  • 翻译缓存失效频率过高
  • Code patching（如 inline cache 更新）的原子性难以保证
  • Profiling 信息的准确性因翻译延迟而失真

3.3 原生 AArch64 HotSpot 已成熟

经过五年（2021–2026）的发展，macOS/AArch64 端口已经完全成熟：

  • JDK 17–21 LTS: 提供生产级 AArch64 支持，性能基准测试表明原生 AArch64 HotSpot 在 Apple Silicon 上的性能全面超越通过 Rosetta 2 运行的 x86_64 版本 [4]
  • JDK 22–26: 持续优化 AArch64 特定的性能特性，包括 Vector API（Incubator）、Foreign Function & Memory API 的 AArch64 后端
  • 多发行版支持: Oracle JDK、OpenJDK、Adoptium (Eclipse Temurin)、Amazon Corretto、Azul Zulu、Microsoft Build of OpenJDK 等均提供 macOS/AArch64 构建版本

简言之，macOS/x64 端口已经完成了其历史使命——帮助用户在 Apple Silicon 早期（2020–2021）保持兼容性。如今，原生 AArch64 端口在功能、性能和稳定性上均已全面超越。

四、对开发者的影响评估

4.1 影响矩阵

影响维度 影响等级 影响说明
个人开发者（已迁移至 Apple Silicon） 极低 无直接影响，已使用原生 AArch64 JDK
个人开发者（仍持有 Intel Mac） 高 无法升级到 JDK 27+，需锁定在 JDK 25 LTS 或更低版本
企业 Java 应用（本地开发环境） 中高 开发环境需统一为 Apple Silicon 或迁移到 Linux/Windows
CI/CD 管线（macOS runner） 中 GitHub Actions macOS runner 需确认架构切换
JNI/JNA 原生库开发者 高 x86_64 原生库需提供 AArch64 版本或通过 Rosetta 2 兼容
Gradle/Maven 依赖（含 native library） 中 部分含 native 依赖的库可能出现架构不匹配
JavaFX 应用开发者 中 JavaFX 27 同步取消 macOS/x64 构建 [10]

4.2 CI/CD 管线调整

对于使用 macOS runner 的 CI/CD 管线，需要重点关注以下变更：

GitHub Actions:

# 旧配置（Intel Mac）
runs-on: macos-13  # x86_64

# 新配置（Apple Silicon）
runs-on: macos-14  # AArch64 (M1)
# 或
runs-on: macos-15  # AArch64 (M 系列更新)

GitHub 已从 2025 年开始逐步废弃 macOS 13 (Ventura) runner，对应的 x86_64 执行环境将不再可用 [11]。开发者需尽快将 CI 管线迁移到 macOS 14+ 的 Apple Silicon runner。

自建 CI 环境:

如果使用自建的 macOS 构建代理（如 Jenkins on Mac），需要确保：

  • 硬件已升级为 Apple Silicon Mac
  • JDK 版本为 AArch64 原生构建
  • 所有构建工具链（Gradle、Maven、Ant）均使用 AArch64 兼容版本

4.3 JNI/JNA 本地代码库迁移

JNI（Java Native Interface）和 JNA（Java Native Access）是 Java 与本地代码交互的桥梁。对于依赖 JNI/JNA 的项目，影响尤为显著：

JNI 原生库 (.dylib/.jnilib):

  • 需要为 AArch64 重新编译所有 JNI 原生库
  • Universal Binary（同时包含 x86_64 和 AArch64）可作为过渡方案
  • 第三方 JNI 库（如 JNA、Netty native transport、JNR-FFI）需确认已提供 AArch64 版本

JNA 自动适配:

  • JNA 在运行时自动加载对应架构的共享库，通常能自动适配
  • 但如果本地库（.dylib）仅提供 x86_64 版本，则需通过 Rosetta 2 运行整个 JVM

迁移建议:

# 检查本地库架构
lipo -info libyourlibrary.dylib

# 构建 Universal Binary
lipo -create libyourlibrary-x86_64.dylib libyourlibrary-arm64.dylib \
     -output libyourlibrary.dylib

4.4 Gradle/Maven 依赖的 Native Library 兼容性

许多 Java 库在底层依赖 native library：

  • Netty: 从 4.1.x 版本开始提供 macOS/AArch64 的 native transport
  • Apache Arrow: 从 5.0+ 提供 AArch64 支持
  • SQLite JDBC: 需使用包含 AArch64 native library 的版本
  • LWJGL / JME: 图形相关库需要 AArch64 对应的原生库

排查方法:

# 查看当前 JVM 架构
java -XshowSettings:properties -version 2>&1 | grep os.arch

# 查看依赖的 native library 路径
java -XshowSettings:system -version

4.5 企业应用的维护成本

对于仍在使用 Intel Mac 的企业开发团队，影响主要体现在：

  1. 版本锁定风险: 无法升级到 JDK 27+，意味着无法获取新的语言特性、性能优化和安全修复
  2. 安全更新窗口: JDK 25 LTS 的安全更新将在约两年后结束，之后 Intel Mac 上的 Java 运行时将不再获得安全补丁
  3. 工具链兼容性: IDE（IntelliJ IDEA、Eclipse）和构建工具（Gradle 8+、Maven 4+）将逐步要求 JDK 21+ 作为最低运行版本
  4. 硬件淘汰压力: Intel Mac 硬件本身也在老化（最后一批于 2020 年发布），性能和可靠性已无法满足现代开发需求

五、替代方案

5.1 方案对比

方案 适用场景 优点 缺点
升级到 Apple Silicon Mac 长期主力开发 性能最佳，官方完整支持 硬件采购成本
使用 JDK 25 LTS 延伸支持 短期过渡 无需更换硬件，安全更新仍有保障 无法使用 JDK 27+ 新特性
通过 Rosetta 2 运行 x64 JDK 偶尔需要 x64 环境 无需额外配置 性能损耗 10-30%，未来可能失效
UTM / Parallels 虚拟化 需要 x64 完整环境 可运行完整 x64 Linux/macOS 虚拟化开销，Parallels 需付费
云端 Intel CI Runner CI/CD 管线 灵活按需付费，与本地架构解耦 网络延迟，持续运营成本
Linux on Intel Mac 延续 Intel 硬件寿命 完整的 Linux JDK 支持 失去 macOS 生态
第三方发行版维护 社区用户 可能继续提供 x64 构建 无 Oracle 官方支持，质量无保障

5.2 Rosetta 2 的残余兼容性

值得注意的是，JEP 8386091 的提案中也保留了一个"反转机制" [1]：

"If a set of credible developers express a clear desire to maintain the port going forward, this JEP can be withdrawn or a follow-on JEP can revert the deprecation." [1]

这意味着如果社区出现有能力的维护者团队接手 macOS/x64 端口，该决策仍然可以逆转。但考虑到 Apple 自身已在 macOS 26 "Tahoe" 中终止 Intel 支持 [6]，这一可能性极低。

此外，对于 Apple Silicon Mac 上的 Intel Mac 用户（即通过 Rosetta 2 运行 x64 JDK），这并非受影响的群体——这些用户应直接使用 AArch64 原生 JDK。

5.3 虚拟化方案详解

UTM (免费，开源):

  • 基于 QEMU，支持 macOS 上的 x86_64 虚拟化
  • 需要在 Apple Silicon Mac 上运行，通过 QEMU 的 TCG 模式翻译 x86_64 指令
  • 性能较低，适合测试用途

Parallels Desktop (付费):

  • 商业级虚拟化解决方案
  • 在 Apple Silicon Mac 上支持运行 ARM 版 Windows 和 Linux
  • 不支持直接虚拟化 x86_64 系统

结论: 虚拟化方案主要适用于 Apple Silicon Mac 用户需要 x86_64 环境的场景，而非让 Intel Mac 用户继续使用新版本 JDK。对于仍在 Intel Mac 上的开发者，最务实的方案仍然是直接升级硬件。

5.4 云端 Intel CI Runner

对于 CI/CD 管线中仍需 x86_64 macOS 环境的场景：

# GitHub Actions - 使用 macOS 13 (最后一代 x86_64 runner)
runs-on: macos-13

需要注意 GitHub 已计划在 2025 年 12 月前完全退役 macOS 13 runner [11]。替代方案包括：

  • 使用 macOS 14/15 runner（AArch64）+ Rosetta 2 运行 x86_64 二进制
  • 使用第三方 CI 提供商（如 Circle CI、Buildkite）的 Intel Mac 队列
  • 使用 self-hosted runner 在自建 Intel Mac 上运行

六、对其他生态的启示

Java 并非第一个，也不会是最后一个放弃 Intel Mac 支持的开发者工具链。这一趋势反映了整个软件行业对 Apple Silicon 迁移的集体响应。

6.1 各生态 Intel Mac 支持现状

技术/平台 当前状态 说明
Java (OpenJDK) JDK 27 起废弃 x64 端口 [1] Oracle 不再维护，社区可能接手
JavaFX 同步 JDK 27 废弃 [10] Oracle 不再发布 macOS/x64 构建
Python (CPython) Intel Mac 降为 Tier 2 支持 [12] CI 测试降级，预编译二进制可能滞后
Rust x86_64-apple-darwin 降为 Tier 2 已于 2024 年降级
Node.js 仍在支持，但测试重点转向 AArch64 社区推动中
Docker Desktop 仍提供 x64 版本 通过 Rosetta 2 在 Apple Silicon 上运行
Go 仍提供 x64 构建 Go 的交叉编译能力较强，影响较小
.NET 仍在支持 x64 macOS Microsoft 仍在发布 Intel 构建

6.2 行业趋势分析

从各生态的演进方向来看，有几个共同特征：

  1. Tier 降级先行: 大多数项目不会立即完全移除 Intel Mac 支持，而是先降低支持等级（如从 Tier 1 降为 Tier 2），逐步减少 CI 测试覆盖
  2. 跟随 Apple 脚步: Apple 自身在 macOS 26 "Tahoe" 终止 Intel 支持 [6]，为各项目提供了明确的时间节点
  3. 社区驱动为主: 与传统商业软件不同，开源项目依赖社区贡献者提供硬件和测试资源，Intel Mac 的硬件稀缺性导致测试覆盖率下降

6.3 开发者的战略建议

  • 统一架构策略: 团队应尽早统一为 Apple Silicon 开发环境，避免双架构维护负担
  • Universal Binary 过渡: 对于发布的 native library，构建 Universal Binary 可提供平滑过渡
  • CI/CD 架构抽象: 在 CI 管线中使用抽象层（如容器化），降低对宿主架构的依赖
  • 关注 LTS 版本: 对于企业应用，锁定 JDK 25 LTS 可获得最长的安全更新支持周期

七、个人技术观点

Java 27 废弃 macOS/x64 端口的决策，从技术和商业角度来看都是合理的，但在执行节奏上仍然值得讨论。

合理性:

  • Apple Silicon Mac 的市场占有率已经足够高，维护 x64 端口的边际价值持续递减
  • 原生 AArch64 HotSpot 的性能优势已充分验证，Rosetta 2 的兼容性层只是权宜之计
  • 释放的工程资源可以投入 AArch64 的深度优化和新特性开发

值得商榷之处:

  • Intel Mac 的实际用户基数仍然不小（尤其是中国等地区的开发者），一刀切的废弃可能过于激进
  • JEP 提案中提到"如果社区出现有能力的维护者，可以反转决策" [1]，但这种措辞实质上将维护负担推给了社区，而非提供过渡期支持
  • 对于 JNI/JNA 生态的下游影响评估不够充分，部分 native library 的 AArch64 移植进度滞后于 JDK 本体

历史类比:

这一决策与 2010 年 Apple 放弃对 PowerPC 的支持有相似的逻辑——硬件架构的演进速度最终会迫使软件栈跟进。区别在于，PowerPC 的过渡有 Rosetta（第一代）作为桥梁，而 Apple Silicon 的过渡有 Rosetta 2，后者的翻译质量远超前代。但即便如此，对于 JVM 这种对运行时性能敏感的环境，翻译层的存在本身就是技术债务。

八、参考来源

  1. JEP Draft 8386091: Deprecate the macOS/x64 Port for Removal. OpenJDK. https://openjdk.org/jeps/8386091
  2. Oracle to end Java support for Intel Macs starting with JDK 27. 4sysops. https://4sysops.com/archives/oracle-to-end-java-support-for-intel-macs-starting-with-jdk-27/
  3. JEP 391: macOS/AArch64 Port. OpenJDK. https://openjdk.org/jeps/391
  4. OpenJDK for Apple Silicon M1: JDK 16/17 ARM64 Support. JavaThinking. https://www.javathinking.com/blog/java-jdk-for-the-apple-silicon-chips/
  5. Intel Mac 终将成为时代的眼泪. CSDN. https://blog.csdn.net/zhiyuan411/article/details/150957046
  6. Apple Ends Intel Mac Support with macOS 26 "Tahoe". TrendForce / 9to5Mac. https://www.trendforce.com/news/2025/06/10/news-apple-ends-intel-mac-support-with-macos-26-tahoe-finalizing-move-to-apple-silicon/
  7. OpenJDK JDK 27 Early-Access Builds. https://jdk.java.net/27/
  8. JDK 8u451 Mac 安装包 aarch64 与 x64 如何选择. CSDN 问答. https://ask.csdn.net/questions/8968072
  9. About the Rosetta Translation Environment. Apple Developer Documentation. https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment
  10. JavaFX 27 for macOS/x64. OpenJFX-dev mailing list. https://mail.openjdk.org/archives/list/openjfx-dev@openjdk.org/thread/OPT4NV4NJSQONM3XN33EKN5ITGK7MMUB/
  11. Dropping Intel Mac to Tier 2 / GitHub Actions macOS 13 Deprecation. Python Discuss / GitHub Changelog. https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100
  12. Python Dropping Intel Mac to Tier 2. Python Core Development Discussion. https://discuss.python.org/t/dropping-intel-mac-to-tier-2/102100/13

技术免责声明

本文基于截至 2026 年 7 月 15 日的公开信息撰写。JEP 8386091 目前仍处于 Draft 状态，最终决策可能发生变化。本文中涉及的技术分析和性能数据基于公开资料和社区测试报告，不构成 Oracle 官方承诺。读者在实际决策前，建议查阅 OpenJDK 官方公告和 JEP 页面的最新状态。本文作者不对因参考本文内容而产生的任何技术决策后果承担责任。