Java 工程师该怎样在 JDK 提 JSON 之后重新选依赖？JEP 540 时代

JEP 540 在 2026 年 7 月正式进入 incubator 阶段，意味着 JDK 终于把 JSON 视为原生 API 而不是外部依赖库的事。这件事表面看是 API 补全，往深里看其实是 Java 生态长期由外部依赖主导的格局第一次被重写，每个 Java 工程师都得重新选一次自己的 JSON 路径。

JEP 540 是什么。先看清楚改动范围。incubator 阶段意味着这个 API 还在 JDK 内部孵化，能用但没正式 release。功能上是 java.util.json 一组类，提供 JSON 解析、生成、JSON Pointer、JSON Patch、JSON Schema 校验五件套，跟 jakarta.json 1.1 规范对齐。这件事社区催了很多年，每次都因为没有维护者愿意长期承诺被搁置，这次是真的动了。

Java 生态过去处理 JSON 基本三选一，Jackson、Gson、JSON-P。Jackson 是 Spring 生态默认捆绑的事实标准，性能最好但启动开销大，Gson 适合 Android 场景轻量，JSON-P 是 Jakarta EE 官方标准，企业应用更认。一个深圳金融科技公司的 Java 架构师公开过他们团队的依赖账，他们接手的 12 个老系统里 9 个用 Jackson，2 个用 Gson，1 个用 JSON-P，重构时跨系统数据对接经常要做序列化层的兼容处理。

JEP 540 上线后第一个会碰到的不是性能问题，是依赖选择的判断标准要换。普通工程师过去选 JSON 库基本只看一个指标，反序列化吞吐量。这个指标在 JEP 540 上线后意义下降，因为很多场景下 JDK 自带意味着零依赖、零冲突、零 CVE。一个上海独立开发者公开过他的判断，他接下来新启动的 Java 项目会直接用 JEP 540，省下来的 Maven 依赖列表从 32 个降到 29 个。

不是所有场景都适合直接切。一是用 Jackson 自定义注解 @JsonView 的系统，这是 Jackson 特有的语法，JEP 540 不兼容，用得深的项目切换成本高。二是需要 JSON Schema 在线校验的服务，金融行业普遍有合规要求，JEP 540 的 Schema 实现是 draft-07 版本，复杂约束场景跟企业自研 Schema 比还有差距。三是 streaming 场景，大文件流式解析 Jackson 的性能优势在 30% 以上，JDK 自带的默认实现在吞吐上还追不上。

另一个反直觉的现象是 JEP 540 上线后，Jackson 团队的反应反而更积极。过去一段时间 Jackson 2.19 主要做的是把启动开销砍掉 40%，同时支持 Java 21 虚拟线程。一个多伦多 Java 顾问公开过他的观察，JDK 自己下场做 JSON 反而逼出了 Jackson 团队的真正实力，因为过去 Jackson 跟 Gson 的竞争是市场份额之争，现在变成跟 JDK 自带的合规与生态之战，赛道完全不同。

底层生态层面还有一个细节值得关注。Spring 团队公开表态在评估是否把 Jackson 从 Spring Boot 默认依赖中剥离。这件事如果落地，意味着 Java 生态长期最稳定的默认依赖组合会发生根本性变化。一个多伦多独立开发者公开过他的判断，Spring Boot 4.0 的 starter 模块可能首次出现可选 JSON 依赖的提示，让开发者显式选择 Jackson / Gson / JEP 540，这件事在过去 Spring 生态是不可想象的。

JEP 540 真正的赢家可能不是 Java 开发者，而是 Jakarta EE 规范团队。JSON-P 4.0 的设计基准过去一直被 Jackson 的事实标准牵着走，JEP 540 上线后 Jakarta 团队第一次有机会跟 JDK 同步演进。一个湾区独立开发者公开过他的判断，Jakarta EE 11 跟 JEP 540 的协同演进可能会让 Java 在云原生 API 领域追平 Go 和 Node.js 的开发体验。

Java 工程师接下来要怎么选。三个判断标准。先看自己项目的依赖复杂度，已经被 Jackson 深度绑定的项目不建议硬切，等 Jackson 2.19 稳定后再评估。轻量工具类项目直接用 JEP 540，省依赖是长期收益。金融和企业合规项目等 JEP 540 升到 preview 阶段再考虑，至少等到 2027 年的 JDK 25 LTS。一个普通 Java 工程师过去很多年不用想 JSON 依赖的问题，现在起每个新项目都得花半天评估这件事。

创业找资源，上乌鸦部落。