Java 平台横切面问答：模块、构建工具、Lombok 与兼容纪律

#

这是一场面向资深工程师的多主题架构师问答摘要，按问题跳转阅读即可；下文将 JEP 261 等规范表述与台上发言人的工程判断分开标注。

模块系统为何普及缓慢？

#

背景
Java 平台模块系统（JPMS） 自 JDK 9 起提供强封装、可靠配置与可链接镜像，但库与应用侧采用率长期偏低。现场提问直指：是设计失败，还是生态还没跟上？

要点

为什么
若构建链不把 --module-path、module-info.java、对 未命名模块 的 --add-exports 等选项做成「默认正确路径」，JDK 再强的机制也难落地。Alex Buckley（演讲者观点）把 Java Agent 当作缩影：命令行可挂 classpath，在 Maven/Gradle 里却常被包装成「又一个依赖 jar」。当前收益主要在演进边界与安全封装；性能红利更多被放在未来，而工具不顺时团队缺少迁移激励。

机制/约束
JEP 261 明确：模块路径与类路径语义不同；落在 classpath 上的代码进入未命名模块，封装弱于具名模块。链接期组装见 JEP 282 与 jlink。

怎么做

javac --module-path lib --module-source-path src -d out \
  --add-modules com.example.app
java --module-path out:lib -m com.example.app/com.example.Main

常见误区
把「模块难用」等同于「JPMS 设计错误」；更常见的是构建/测试/Agent 插件仍按 classpath 思维编排。

延伸阅读

• JEP 261 — 模块系统
• jlink 手册 — 自定义运行时镜像

jlink 愿景、库模块化与 8→11 阵痛

#

背景
理想路径是用 jlink 裁出只含 java.base 与业务依赖模块的运行时镜像再进容器；现实是第三方库大量仍以未模块化 jar 分发。

要点

为什么
演讲者观点：库不模块化，应用侧就很难有动力做端到端模块化与 jlink 镜像。许多 8→11 升级破损来自 JEP 260 起的内部 API 封装（及后续 JEP 403 强封装），不宜笼统归咎 JPMS。关于 sun.misc.Unsafe：JEP 260 将其列为 JDK 9 仍不封装的 critical API；JEP 403 写明强封装下 sun.misc.Unsafe will remain——与「Unsafe 已不可用」的传言不一致；出问题的是其他内部 API 消费者。

机制/约束

jlink --module-path $MODPATH --add-modules com.app,jdk.unsupported \
  --launcher app=com.app/com.app.Main --output runtime

怎么做
先核对依赖是否仍反射 sun.* / jdk.internal.*；再决定是否编写 module-info 或依赖 automatic module 名。

常见误区
把 Spring 等框架「已模块化」当作全行业现状（本场提及，未在 OpenJDK 文档核实）；忽略 automatic module 与真实 module-info 的差异。

延伸阅读

• JEP 260 — 封装大部分内部 API
• JEP 403 — 默认强封装 JDK 内部 API

classpath 上的库为何「默认透视封装」？

#

背景
JDK 模块可 exports 控制可见性；作者发布的普通 jar 若被用户放在 classpath，则整体进入未命名模块，包级「私有」在反射面前仍脆弱。提问者质疑这对库作者是否公平。

要点

为什么
JEP 261：classpath 代码位于未命名模块，可通过 --add-exports pkg=ALL-UNNAMED 等方式放宽边界。演讲者观点分歧：Alex Buckley 称跑进程的人选择权最大，应明确引导 module path；Ron Pressler 称 classpath 与 module path 并列、无单一「默认」；Brian Goetz 承认默认体验有问题，长期方向是逐步弱化 classpath 习惯，但会触怒部分用户，故在收紧与兼容间权衡（「damned if you do, damned if you don’t」）。

机制/约束
规范描述机制差异，不裁决「公平性」。

怎么做
库作者若希望用户走模块路径：在 README 与构建产物中写明 --module-path 启动示例；勿假设「包私有 = JDK 级强封装」。

常见误区
要求 JDK 给第三方 jar 与平台模块同等级别的强封装开关——当前平台策略更倾向生态迁移而非对称开关。

延伸阅读

• JEP 261 — 未命名模块与类路径

Lombok：减少样板，还是编译器公民性问题？

#

背景
企业仍在 Java 25 上强推 Lombok；台上被问：你们是敌人、盟友，还是会让它自然过时？

要点

为什么
Brian Goetz（演讲者观点）：Lombok 要解决的样板痛点合理，但实现上通过未在 JLS/JVMS 中规定的接口改写字节码/AST，属于对编译器生态的「坏公民」；存在完全守规矩的平行宇宙版本，属工具作者选择。其绑定可变 JavaBean + getter/setter 语义，与平台多年倡导的不可变、显式构造方向相悖；生成 Javadoc 需 delombok 是异味。更可能拖慢而非加速风格现代化。官方正道是 javac 注解处理（-processor、-processorpath）；Immutables、AutoValue 等走注解处理器路线（列举为演讲者观点）。

机制/约束
OpenJDK 文档未评价 Lombok；只规定注解处理扩展点。

怎么做

javac -processor com.google.auto.value.processor.AutoValueProcessor \
  -classpath auto-value.jar:.

常见误区
把「少写代码」等同于「编译器集成无成本」；在库对外 API 上依赖预览或私有编译器钩子。

延伸阅读

• javac 手册 — Annotation Processing
• Project Lombok 官方站点（实现细节以项目文档为准）

构建工具跟不上 JDK 时，语言组该接管吗？

#

背景
Go 将 go build 与语言一体交付；Java 侧 Maven/Gradle 对预览特性、模块路径的支持时常滞后，是否应由 JDK 团队做「官方构建」？

要点

为什么
Brian Goetz（演讲者观点）：历来优先 JDK 独占能力（如模块链接、预览开关），但承认社区在构建工具上交付不理想，可能不得不从语言/库挪资源——已是高优先级。Alex Buckley（演讲者观点）：「社区 fallen down」不是 Maven/Gradle 维护者个人的错；大量商业用户几乎不资助这些项目，应通过基金会等渠道资助工具链。机制旁证：预览需 javac --enable-preview 与运行时 --enable-preview（JEP 12），构建插件必须透传。

怎么做
在 CI 模板中锁定 --release + --enable-preview 的 Maven maven-compiler-plugin / Gradle JavaCompile 选项；升级 JDK 时先跑依赖库的模块/预览兼容性矩阵。

常见误区
等待 Oracle 发布替代 Maven 的单一官方构建器——本场未承诺；更现实的杠杆是资助与插件质量。

延伸阅读

• JEP 12 — 预览特性与工具链
• Apache Maven Compiler Plugin 文档

会不会有一天抛弃兼容，推出「Java Next」？

#

背景
序列化、遗留并发原语、类型系统历史包袱让开发者频繁撞墙；社区偶发「重写一门 Java」情绪。

要点

为什么
Brian Goetz（演讲者观点）：不会跳过 Java 28/29 进入模糊的「Java Next」并扔掉兼容；若变革值得做，会带可执行的迁移路径与刻意重设计，而非 bait-and-switch。「Compatibility—we’re all about compatibility」；断裂成本极高，值得做的事会用多阶段迁移完成。旁证：JEP 223 体现版本号与发布节奏纪律，非兼容哲学的完整法条。

机制/约束
平台能力通过 JEP 渐进引入（预览/孵化器/正式），而非大爆炸替换。

常见误区
把语言演进缓慢等同于团队「不敢改」；许多改动卡在生态迁移成本而非缺乏想法。

延伸阅读

• JEP 223 — 新版本号方案
• JEP 12 — 预览特性作为低风险试验通道

什么该进 JDK，什么该留在生态？

#

背景
为何当年没有内置 HTTP Client？为何不把 Jackson「搬进」JDK？

要点
Brian Goetz（演讲者观点）：在有限人力下，只有 JDK 能做的优先（类文件 API、VM 语义），再填竞争力缺口，最后主观评估社区 ROI。Paul Sandoz（演讲者观点）：也看 JDK 自身是否越来越需要该能力——例：虚拟线程转储已支持 JSON（jcmd Thread.dump_to_file -format=json）；「用 JSON 配置 JDK」仍为设想。Brian：不会把生态库原样 plop 进 JDK——历史上多次迁入后以昂贵方式移除；生态库的「当下最好」与 JDK 需要的「面向几十年的 X」不是同一种兽（ASM vs 类文件 API 类比，演讲者观点）。已核实范例：JEP 321 将 HTTP Client 自 JEP 110 孵化器标准化为 java.net.http。

延伸阅读

• JEP 321 — HTTP Client API
• jcmd 手册 — Thread.dump_to_file

结构化并发还要预览多久？

#

背景
StructuredTaskScope 多轮预览，开发者关心何时可写进库 API。

要点
Ron Pressler（演讲者观点）：已非常接近摘掉预览，因仍有少量预览点，可能再 preview 一轮；应用可在预览下使用，不建议库在预览 API 上定型。Alex Buckley（演讲者观点）：「反馈」指真实试用体验，非空想 redesign；以 HTTP Client 类比——Java 9 亮相后长期安静，临近收尾才涌入反馈，Java 11 定稿延续至今；JEP 517 显示 HTTP/3 仍在演进。文档侧：JEP 533（JDK 27 第七次预览）写明 preview the API once more，比口语更具体。

延伸阅读

• JEP 12 — 预览特性
• JEP 533 — 结构化并发（第七次预览）

Project Babylon 何时进入正式流程？

#

背景
Code reflection、GPU/SQL 等实验方向需要社区试什么？

要点
演讲者观点：已有 Submitted 状态 JEP，沿 incubator 推进；时间表「就绪再就绪」。文档可核对：Project Babylon、JEP 8361105 — Code reflection（孵化器，Submitted），模块 jdk.incubator.code，启用示例 javac --add-modules jdk.incubator.code。Alex Buckley：演讲者观点称 Babylon 比多数特性更需要社区反馈。

延伸阅读

• OpenJDK Project Babylon
• JEP 11 — 孵化器模块

Stream API 会做系统性性能重写吗？

#

背景
Stream 的多态与装箱带来开销，实践里常被建议改回 for 循环。

要点
Brian Goetz（演讲者观点）：设计优先表达清晰；多数场景数据量小，深挖 Stream 框架 ROI 不高；曾在「人类可读」与「机器友好」间优先人类；Valhalla 等或开辟后续路径。John Rose（演讲者观点）：视为 loop customization；megamorphic cliff 限制组件复用；Babylon/stream fusion（Scala 先例）或给 JIT 更好静态结构——数年尺度，非下个小版本。注意：Stream 属 Java 8 java.util.stream 历史交付；勿将今日 JEP 189（Shenandoah GC）误作 Stream 依据。

延伸阅读

• java.util.stream 包文档
• OpenJDK Project Babylon

AI 能否加速 OpenJDK，架构师怎么用？

#

背景
Backlog 巨大，Conformance 测试维护繁重，AI agent 能否分担？

要点
Brian Goetz（演讲者观点）：能帮忙，关键在如何帮，尚无定论。Alex Buckley（演讲者观点）：OpenJDK 不能像普通 GitHub 仓库随意 PR；请勿用 AI agent 骚扰维护者——流程见 OpenJDK Developers’ Guide（需 OCA、赞助人、JBS）。Paul Sandoz 等（演讲者观点）：试验用 AI 随 spec 更新测试。John Rose（演讲者观点）：援引 Amdahl 定律——快 70% 不等于剩 30% 免费；对 agent 不信任、近期也不打算信任；需防「永远通过的测试」式取巧。

延伸阅读

• OpenJDK Developers’ Guide
• OpenJDK 贡献流程概述

紧凑对象头能否显著缩小堆？

#

背景
JEP 519（JDK 25 产品化）延续 JEP 450：对象头由 96–128 bit 降至 64 bit（8 字节），相对常见 12 字节头约省 4 字节/对象。

要点
John Rose 等（演讲者观点）：理论可回收内存，实际取决于碎片与分配模式——try it, measure it。JEP 450 引用 Lilliput 实验：live data 常降约 10%–20%，不宜写成确定比例。启用（JDK 24 实验期示例）：-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders；JDK 25 见 JEP 519 正文。默认开启时间表见 JEP 534（提议 JDK 27），抓取日未核实是否已交付。

延伸阅读

• JEP 450 — Compact Object Headers（实验）
• JEP 519 — Compact Object Headers（产品，JDK 25）

参考与延伸阅读

#

• JEP 261 — Java 平台模块系统
• JEP 282 — jlink：Java 链接器
• jlink 命令参考
• JEP 260 — 封装大部分 JDK 内部 API
• JEP 403 — 强封装 JDK 内部元素（保留 Unsafe）
• JEP 12 — 预览特性：编译与运行双开关
• JEP 533 — 结构化并发（第七次预览，JDK 27）
• JEP 8361105 — Code reflection 孵化器草案
• JEP 321 — 标准 HTTP Client API
• JEP 517 — HTTP/3 for the HTTP Client API
• javac 手册 — 注解处理与 --enable-preview
• OpenJDK Developers’ Guide — 贡献与赞助人流程
• JEP 450 / JEP 519 — 紧凑对象头实验与产品化
• JEP 445 / JEP 495 — 简易入口与实例 main 预览链
• JEP 454 — Foreign Function & Memory API

深度边界：本文为约 58 分钟广度问答的摘要，非 JPMS/Maven 实现教程，亦未剖析 Lombok 内部 hook；标为「演讲者观点」处请结合你方 JDK 版本与依赖树自行验证。