我与Java代码格式化工具的爱恨情仇：从google-java-format到open-java-format

免责声明：我不想把这个变成“Java 格式化工具周”，但我在不久前启动了自己的项目，我觉得是时候让它走出隐身模式了。

多年来我一直在写 Java，Sun 代码规范是我最喜欢的床头读物。这些年来我见过许多变体，即使它们后来变成了 Oracle 代码规范，也仍然是那几页关于如何使用标准类库编写 hello world 应用的指南。不知为何，我一直没能接受 Google 规范：太有 C 风格，缩进很小，屏幕上列数太少，等等。

后来我不得不大量使用 Terraform 和 Go，你无法想象，写代码时不用再想“点号放在行首还是行尾？”、“参数用几个空格？”、“大括号要放在同一行吗？”以及许多许多类似问题，是多么自由。还有那些关于缩进错误的审查评论……之后我加入了一个使用 google-java-format 作为 CI 质量门禁的项目。第一个月我很讨厌它，之后我就离不开它了。所有那些关于仪式和巫毒娃娃的知识都被抹掉了，很多代码审查摩擦消失了，我大脑中很大一块也被释放出来，因为我不再需要辨认每个开发者的笔迹（是的，我相信每个开发者都有自己的笔迹）。然后我发现了 palantir-java-format，它是 google-java-format 的一个 fork，布局紧凑得多，对响应式代码的处理非常出色，还有一个几毫秒就能运行的原生二进制文件。

但没有什么能永远持续。新的 Java 版本不断发布，但这些项目中的未解决问题状态从未改变，PR 一直挂着、检查是红的，最近几个版本看起来像是与内部基础设施同步的杂务。作为一名格式化工具爱好者，这对我来说很重要。每当我加入一个新项目并想引入 Java 格式化工具时，总是同样的两个问题。它叫什么？Palantir？嗯…… 那到底是谁在构建制品？

有了 AI 之后，情况变得更糟。每个模型、每个会话对代码风格都有自己的想法，无论你在 .md 文件里描述得多么精确。一个代理把每个参数都单独换行，另一个把整条流管道塞进一行 200 个字符里，第三个则“好心”重新格式化了从未让它碰的文件，于是一个两行的修复变成 400 行空白噪声差异。然后 CI 拒绝它，代理又按自己的方式“修复”回来，循环再次开始。

这就是我 fork Palantir 仓库并给它做了大幅改造的原因。它不是原型，而是一个可用的发布版本，带有 IntelliJ IDEA 插件、Gradle 集成，以及面向所有主流平台的原生二进制文件。我把整个 CI 基础设施迁移到了 GitHub Actions，添加了制品签名，添加了对 Java 27 的支持，并修复了 Google 和 Palantir 问题跟踪器中一些最烦人的 bug。接下来：把所有自定义依赖替换为开源替代品，修复 Error Prone 的发现，并进行一点“吃自己的狗粮”，也就是用这个格式化工具本身格式化整个代码库。我还有一些想法，想让使用响应式库和 Map 的代码更具表现力，但这些会留到下一个大版本。2.98.0.x 系列基于 palantir-java-format 2.98.0，包含 bug 修复、重构以及平台或工具链更改，例如 2.98.0.2 中新增的 Windows 原生二进制文件。

文档：openjavaformat.dev

GitHub 仓库：github.com/openjavaformat/open-java-format

我很想听听你的想法，欢迎任何反馈！
分享此页面