Не раз уже поднималась тема про форматтеры для 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 (проверил только последнюю версию с сайта).

• ⚙️ Конфигурация: отсутствует

Чтобы проект заслужил свою отдельную версию, в планах убрать все зависимости на библиотеки от Гугла и Палантира, провести чистку кода от ошибок и проблем, которые подсвечивают сканеры.

Буду рад обратной связи и звездочки на проекте.