← #810

Java 27 正式发布

文章摘要

原文是 Mark Reinhold 于 2026 年 9 月 15 日发到 OpenJDK announce 邮件列表的一封通告，内容极其克制：JDK 27，即 Java 27 的参考实现，正式进入 GA（General Availability）。8 月 20 日发布的 build 35 是第二个 RC，此后没有再报出 P1 级缺陷，因此 build 35 直接成为 GA 版本，可用于生产。Oracle 提供的 GPL 协议 OpenJDK 构建在 jdk.java.net/27，其他厂商的构建随后跟进。

本次发布包含九个 JEP：

523：让 G1 成为所有环境下的默认垃圾收集器。 过去在「小机器」上 JVM 会退化到 Serial GC，现在统一为 G1，这是本次对运行时行为影响最直接的一项。
527：TLS 1.3 的后量子混合密钥交换。 把抗量子算法与经典算法组合起来做密钥协商，属于整个行业当前的迁移浪潮。
531：Lazy Constants（第三次预览）。 提供一种受语言与 JIT 支持的延迟初始化常量机制，试图取代手写的双检锁和 holder class 惯用法。
532：模式匹配、instanceof 与 switch 中的原始类型（第五次预览）。
533：结构化并发（第七次预览）。
534：默认启用紧凑对象头（Compact Object Headers）。 对象头从 12/16 字节压缩到 8 字节，对堆内小对象密集的应用能带来可观的内存与缓存收益，是这个版本里最实在的性能改进之一。
536：JFR 进程内数据脱敏。
537：Vector API（第十二次孵化）。
538：加密对象的 PEM 编码（第三次预览）。

外加照例的「数百项小改进和数千个 bug 修复」。

值得注意的是这个版本的性质：没有任何正式的语言层变更（预览特性不算），九个 JEP 里五个是预览或孵化的再次迭代。它也不是 LTS 版本——Java 25 才是当前的 LTS。真正被大量开发者期待的 Project Valhalla（值类型）要到 Java 28 才以预览形式登场，而且据评论区讨论，特化泛型（specialized generics）及其性能红利已经被从第一阶段中砍掉了。Vector API 之所以孵化了十二轮迟迟不 GA，正是因为 JDK 团队决定等 Valhalla 的值类型定稿之后再固化其接口。

HN 评论精华

这个帖子拿到了 347 分、四百多条评论，但真正讨论 JEP 内容的比例不高，绝大部分能量流向了两个老话题：Java 的发布节奏，以及「2026 年还该不该用 Java」。

冷笑话仍然管用。 taspeotis 贴了那个三十年前的段子：「咚咚。」「谁啊？」……长时间停顿……「Java。」有人抗议这是 90 年代的老梗，nairboon 回敬「还好笑就说明它活下来了」，HelloUsername 则补刀「那个停顿本身就持续了三十年」。也有人不服：pohl 说「停顿的是 JVM 在启动」，nsxwolf 干脆用 JEP 523 正面回应——G1 现在是默认 GC 了。Betelbuddy 抬出 LMAX Disruptor 提醒大家高频交易团队一直在用 Java。

与 .NET 的对照。 一位 C# 开发者 moomin 的观察被顶得很高：Oracle 的发布节奏大约是微软的两倍频率；Java 里一个特性经常要经历两轮以上正式版预览，而 .NET 很少这样；微软倾向于把更多东西塞进平台本身、留给社区的更少；最后，这封公告读起来像开源项目「做完了，累了」的口吻，完全没有微软发布会的排场。

回复分成几派。多数人认为六个月固定节奏恰恰不是「快速迭代打破一切」，而是相反：dcminter 和 Romario77 都回忆了从前 Java 大版本一拖数年、特性错过发车就要再等几年的痛苦，固定车期加上预览机制让半成品可以先见光而不必立刻承诺兼容性；gf000 说固定档期反而让开发更从容——没赶上就等下半年。leapingdog 引用了 JDK 团队自己的说法「后发者优势」，认为 Java 在语言特性上刻意让别人先试错是好事。

kllrnohj 提出了一个更技术性的批评：Oracle 把「语言版本」和某一个具体运行时的发布周期绑死了，Java 27 里语言变更为零，除了 TLS 的一个小库改动之外全是 OpenJDK 运行时内部的事；如果你用的是 GraalVM，Java 27 对你几乎不存在。OpenJDK 项目负责人 pron 亲自回复了这一点：Java 的语言、库和 VM 多年来是作为统一平台协同设计的，几乎每个重要特性都同时有语言、库和 VM 的人在做，团队开工时往往都不知道最终成果会落在哪一层；因此根本不存在「语言版本」和「运行时版本」的区分，只有一个由 JCP 批准的平台规范版本，这样在兼容性和演进上反而更省事。hyperpage 补充说只数 JEP 会严重低估变更量，javaalmanac 的 API diff 里有大量不体现为 JEP 的库改动。

「2026 年新项目该用 Java 吗」。 Horffupolde 的这句提问衍生出全场最长的子线程。pron 的归纳被广泛引用：如今 Java 主要用在那些必须高可靠、高性能、要活很多年的绿地项目上——银行、电信、金融、政府、国防、制造控制、物流航运、流媒体、零售、医疗；它通常不会是「更有趣的软件」的首选，比如 Python 类型检查器、JS 打包工具或者 TUI 文件管理器。这段话的自嘲意味被不少人欣赏，也有人（rohan_、azuanrb）反驳说任何主流语言都能做到可靠，银行电信内部也远非铁板一块。

支持派的理由集中在生态稳定：rwyinuse 说 Java + Spring 的组合让你十年后还能维护，不用把框架和半数依赖换一遍；ivan_gammel 分享了具体案例，选 Java 是因为「没有 npm 供应链闹剧，没有『我的 Go 微服务怎么对接客户的 SOAP 接口』的问题，招人周期两个月以内」；t0mas88 补充了一个新论据——类型严格、魔法少的语言对 AI agent 特别友好，因为写错了直接编译不过，而不是留下一个 Claude 看不见的运行时问题。unscaled 立刻反驳：这个论据对 TypeScript、Go、Rust 同样成立，Rust 的类型系统甚至能挡住 Java 挡不住的数据竞争和资源泄漏。

反对派的最大火力点是空安全。gentlewater 直接说「还是没有 null safety，对我就是一票否决」。arein3 期待 Valhalla 能顺带解决，rf15 泼冷水指出通用空安全已经不是 Valhalla 的核心目标，只是特定条件下的副作用。MrBuddyCasino 说如果 null safety 真的落地，「我可能就没理由继续用 Kotlin 了，Java 已经变得太好用」。也有人推荐 NullAway + JSpecify 注解这套现成方案，rendaw 则指出房间里的大象是标准库集合类——因为一部分方法早于泛型存在，它至今都不是类型安全的，而集合又核心到没人能就第三方替代品达成共识。

反向的批评。 liampulles 给出了一个不常见的角度：Java 不断引入令人兴奋的新功能，恰恰是他厌恶并主动回避它的原因。他的论证是，一门语言（及其生态）的可能性空间越大，被误用和写出晦涩代码的余地就越大；再加上时间和一批能力参差的轮换开发者，烂代码堆积的速度会比「更简单」的语言更快。他强调这不是说 Java 写不出好代码，而是在 Java 里「足够能用的实现」存在极多变体，其中不少是 package-protected abstract static 的恐怖秀。

其他零散但有意思的点。 Good4boothee 不喜欢 JEP 531，认为 Lazy Constants 是 Optional 的重演——我们是不是太害怕扩展语法了，以至于宁愿加一个类也不肯在 final 前面加个 lazy 关键字。pineappletooth_ 报告了行业现实：银行还在用 Java 8，他所在的公司用 17，政府单位的招聘要求里还能看到 Java 7；spopejoy 解释了原因——大公司里 JVM 部署归系统管理员管，开发者碰不到，而 Java 升级的好处几乎只惠及开发者，很少带来用户要的功能，所以没人愿意为此承担哪怕微小的风险。znpy 提醒那些「爱 Java 恨 Oracle」的人：Java 是开源的，你可以从红帽等厂商拿 JDK，一辈子不和 Oracle 打交道。最后 jan_m_savage 的总评相当传神：这个帖子读起来像是「如何在不明说的情况下打一场语言圣战」。