Снова про Java форматтеры

Не раз уже поднималась тема про форматтеры для Java, вот всего пару лет назад выкладывали перевод статьи с обзором текущего состояния подобных утилит

https://habr.com/ru/companies/spring_aio/articles/846278/
Можно сказать, что у основных игроков особо ничего не поменялось за последние два года - у palantir появился native build, но похоже, что развитие продукта подморозили из-за каких-то внутренних процессов в компании. Issue и PR остаются без ответа, так и не появилась поддержка новых версий Java - импорт модулей, source-without-class; интегрирование в системы сборки и CI процессы остается сломанным и т.п. Разработчик из Netflix попытался склонировать google-java-format в очередной раз (https://github.com/Netflix/jfmt), но пока проект находится на начальных стадиях, у него закрыты внешние PR и всё это развивается в рамках своих тулзов, так что это опять ограниченный open-source какой-то.
Однако, что реально поменялось за это время и не заметил только слепой - это приход ИИ в разработку, и не только для написания тестов или утилит, но и для написания основного рабочего кода приложения. И тут в полной мере вылезло отсутствие простого, открытого, поддерживаемого продукта, который быстро можно подключить к своему проекту и который будет достаточно открытый для того чтобы поправить в нем ошибки. Можно сколько угодно пытаться грузить conventions внутрь LLM, но каждая модель будет читать ее по своему и писать код в своем стиле. А делать ревью и внутри себя постоянно переключаться через разные почерки на проекте, становится невыносимо.
И что стало особенно важно - необходимо посмотреть подпись на артефакте и проверить, что использовались общедоступные сервера сборки, которые можно и у себя реплицировать в случае чего. Несколько раз, в разных проектах, я заходил на разговор об использовании palantir-java-format и каждый раз было одно и то же - Как-как он называется? Палантир? А как он собирается?
Поэтому, когда не было реакции на мои PR, пришлось импровизировать и получился проект Open Java Format https://openjavaformat.dev или на Github https://github.com/openjavaformat
В качестве основы был использован palantir-java-format, для поддержки maven взял fmt-maven-plugin. Вся инфраструктура сборки открытая на Github Actions, публикация на Maven Central, Gradle Plugins, JetBrain Marketplace выполняются через CI. Как базовую версию взял Java 21 и Gradle 9.
Если брать критерии из предыдущей статьи, то я не смог бы оценивать как хорошо-плохо, поэтому напишу, что получилось.
🏗 Maven: есть плагин для запуска форматирования или проверки. Версия форматтера не фиксирована, поэтому можно будет обновлять без потери совместимости.
🏗 Gradle: тоже есть готовый плагин для запуска форматирования или проверки. Он привязан к сборке.
🏃♂️ Скорость: у jar такая же как у google-java-format и palantir-java-format + поправил регрессии, которые висят как открытые баги у проектов. У native сборки скорость работы на порядок лучше - форматирование отдельных файлов занимает миллисекунды.
✨ Красота: лучший и самый компактный вариант из доступного, сложный реактивный код умещается на экране, а не превращается в лесенку из лямбд.
🚀 Эргономичность: есть self-executable jar со всеми зависимостями, есть native для Linux, MacOS и Windows. Есть готовый git hook для проверки на машине разработчика, есть инструкции для AI, есть action для проверки форматирования в CI. Одна версия работает с исходниками до Java 27.
🧠 IntelliJ: плагин есть в JetBrains Marketplace, работает с jar версией и с native. В релизе есть zip, который можно поставить в форки Idea, такие как OpenIDE (проверил только последнюю версию с сайта).
⚙️ Конфигурация: отсутствует
Чтобы проект заслужил свою отдельную версию, в планах убрать все зависимости на библиотеки от Гугла и Палантира, провести чистку кода от ошибок и проблем, которые подсвечивают сканеры.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.