事情的源头是 OpenJDK 社区提出的一份 JEP 草案，标题直白：弃用并计划移除 macOS/x64 端口。
从 JDK 27 开始，Intel 芯片的 Mac 上跑 Java，官方就不再提供支持了。
Intel Mac 到底是哪些机器
先把范围划清楚。”Intel Mac”指的是苹果 2006 年从 PowerPC 切到 Intel 芯片、一直到 2020 年启动 Apple Silicon 迁移之前卖出去的那一整条产品线。只要机身上没贴 M1、M2、M3 这些芯片标签，就在这个阵营里。这个跨度将近十五年，覆盖的型号相当多。
真正要命的是最后一批，这里面那台 2020 款 13 英寸 MacBook Pro 我格外有感触，身边不少同事的工位上现在还摆着它，说白了就是英特尔的 x86 芯片，用了快六年，照样扛着日常开发。2019 款 Mac Pro 那边也一样，塔式机身、用料扎实，皮实耐用是出了名的，团队里还真有同事拿它当主力机用到现在。
JDK 27 不再构建 Intel Mac 版本
Apple 自己转向 ARM 是一回事，Java 社区愿不愿意继续陪跑 Intel Mac，是另一回事。这次两边选择了同步收场。
OpenJDK 邮件列表工程师说得很直接：”Oracle engineers will thus stop maintaining the macOS/x64 port as of JDK 27.” 具体到工程实现上，从 JDK 27 开始，如果你在 macOS 上为 x64 架构配置编译，构建脚本会直接报错退出：
1 | The macOS/x64 port is deprecated and may be removed in a future release |
想强行编译也不是完全没门，加一个 --enable-deprecated-ports 参数可以压下这个致命错误，但控制台还是会甩出一句警告：平台不保证这个端口能编译成功，更不保证编译出来的 JDK 能正常跑。更实质的一刀，是 macOS/x64 的编译测试被从 GitHub Actions 的默认自动化流水线里整个摘掉了。没有官方 CI 兜底，这个端口的代码质量只会越来越难说。
是时候换机器了
Python 的 Anaconda 从 2025 年 8 月 15 日起停止为 Intel Mac 构建预编译包；CPython 核心团队把 macOS x86_64 从”一级拦截支持”降到了”二级后备支持”。Rust 把 x86_64-apple-darwin 构建目标降级为 Tier 2，官方不再对这个平台的内存兼容性问题做硬性背书。Node.js 早在 2024 年中旬就把 macOS x64 降为 Tier 2，并预告从 2028 年起该平台将被标记为”完全实验性”。.NET 这边更彻底：Visual Studio for Mac 在 2024 年 8 月已经退役，.NET 10 的官方支持底线只覆盖苹果仍在维护的最新两个系统版本。
JDK 27 又有性能提升
抛开 Intel Mac 这条线不谈，JDK 27 这个版本本身，是 JVM 在内存布局上一次挺大的动作。
G1 垃圾收集器 (JEP 523) 计划成为所有环境下的默认选择；紧凑对象头默认启用 (JEP 534)，把 64 位架构上的对象头从 96 位压缩到 64 位，直接影响堆内存开销和 CPU 缓存命中率；Vector API 也进入第十二次孵化 (JEP 537)，瞄准的是媲美 C/C++ 的 SIMD 向量计算能力。
密码学性能上也有肉眼可见的提升，X25519 密钥生成在 AArch64 上大约提升 55%，在 x86_64 上大约提升 50%。两边都在涨，只是 Apple Silicon 那边涨得更狠一点，这也侧面说明了为什么 JVM 团队愿意把资源更多倾斜到 ARM 这条线。
这些特性跟你用不用 Intel Mac 关系不大，但如果你还停留在旧 LTS 上不打算升级，等于是在跟这批内存布局层面的优化说再见。