От имени core команды Axelix и всех, кто внёс вклад в сообщество, я хочу заявить: мы наконец это сделали.

Axelix, наконец, выходит в GA (Generally Available — общедоступная версия)!

Для тех, кто не знает - Axelix это продукт с открытым (Open Source) ядром, который позволяет выявлять распространённые проблемы, подводные камни и неэффективности в Java-приложениях.

Ядро продукта лежит на GitHub (нам будет приятно получить от вас звезду ?) - можете использовать, это бесплатно.

В этом посте я хочу поделиться историей и мотивацией, стоящей за продуктом в целом. Надеюсь, вам будет интересно.

История. Большое «Почему» за Axelix

Java довольно интересный язык и экосистема в целом. Думаю, немногие станут спорить, что он довольно старый и был одним из первых так называемых «объектно-ориентированных» языков, который действительно получил массовое распространение. Java был и остаётся хребтом современного enterprise.

Всем, кто утверждает, что Java мёртв, я рекомендую заглянуть в опрос JetBrains State of Developer Ecosystem или даже в опрос Stack Overflow за 2025 год (Stack Overflow, к сожалению, уже стал частью истории). Очевидно, что Java как язык и «экосистема» вокруг него (включая Kotlin) всё ещё относительно популярны, и это остаётся правдой.

Экосистемы вокруг языков

Опытный разработчик знает, что сегодняшние экосистемы, развивающиеся вокруг языков, как правило, очень разнообразны. Например, давайте поговорим о JavaScript.

Если мы сделаем довольно грубую ошибку и решим, что запускать JavaScript на сервере - это хорошая идея, то, скорее всего, будем работать с какой-то базой данных. А значит, нам также понадобится фреймворк, библиотека для работы с базой данных, например ORM (я знаю, что можно обойтись и без неё, но оставим это в стороне).

И в JavaScript у нас довольно много вариантов:

• Prisma

• TypeORM

• DrizzleORM

• Kysely и так далее.

Мы можем довольно уверенно утверждать, что Prisma ORM это вероятно, самая используемая ORM в JavaScript. Но заметьте, что она далека от того, чтобы быть безоговорочной ORM для JavaScript.

То есть утверждать, что Prisma это безоговорочный лидер в мире ORM в JavaScript довоьно спорно. Я хочу подчеркнуть: даже по собственной оценке популярности от Prisma, она не сильно опережает конкурентов. Они все очень близки. Так что способ, которым люди работают с базой данных в JavaScript, может сильно отличаться от команды к команде.

Определяющая черта экосистемы Java

В Java, если мы возьмём ту же самую проблему (работу с базой данных), то быстро осознаем, что индустрия сильно сконцентрирована.

В целом можно аккуратно утверждать, что Spring Data JPA как решение поверх Hibernate занимает более 50% всех решений для доступа к данным, не говоря уже об ORM. Помню, некоторое время назад Джош Лонг (Josh Long), всеми любимый Developer Advocate Spring, опубликовал в X (бывший Twitter) опрос об использовании технологий доступа к данным:

Мы, конечно, должны признать, что существуют быстрорастущие альтернативы JPA такие как jOOQ, но Spring Data JPA доминирует в этой области. Так что способ, которым мы работаем с базой данных в Java (по крайней мере на стороне сервера, а server-side это то, где сейчас почти вся Java), относительно чётко определён и вращается вокруг Spring Data JPA.

Но это ещё не всё, речь не только об ORM или библиотеках доступа к данным. Это нечто большее.

Spring Framework как феномен

Мы не можем говорить об экосистеме Java и не говорить о Spring Framework. Если мы заглянем в упомянутый отчёт Developer Ecosystem State от JetBrains, то получим следующие данные. Я тщательно собрал их для вас - делитесь ими свободно, как хотите. Также обратите внимание, что респонденты могли выбирать несколько вариантов:

Это (по крайней мере, насколько мне известно) одни из самых свежих и заслуживающих доверия данных, что у нас есть. Большое спасибо JetBrains за их публикацию.

Так что да, хотя другие экосистемы тоже растут, например Quarkus вместе со своим Quarkiverse, им всё ещё предстоит очень, очень долгий путь, чтобы догнать Spring Framework. Поэтому в конце 2025 года (готов поспорить, что и сегодня) можно смело утверждать:

Наиболее распространённое Java-приложение, которое с большим отрывом представляет более половины серверных развёртываний Java - это приложение на Spring Framework.

Опять же, это просто данные, вы можете скачать их и проверить сами.

Но даже если мы рассмотрим разные экосистемы: Spring Framework, Quarkus или Micronaut и так далее — мы быстро осознаем, что это не просто «библиотеки» или «фреймворки» в традиционном смысле. Они сами являются большими фреймворками, которые выстраивают вокруг себя целую суб-экосистему.

Например, вы работаете с данными? Что ж, у вас есть

• Spring Data в Spring

• Jakarta Data в Quarkus

• Micronaut Data в Micronaut

О, вы хотите отправить HTTP-запрос? Самая распространённая вещь на бэкенде! Что ж, у нас есть:

• Spring Cloud Exchange/OpenFeign в Spring

• RestClients в Quarkus

• Declarative HTTP Clients в Micronaut

Обратите внимание, что у каждого фреймворка есть своё собственное решение. Мы остаемся в рамках экосистемы framework-а.

В других экосистемах, например в JavaScript на стороне сервера, мы можем использовать:

• ExpressJS для веб-сервера

• Axios для отправки запросов

• Prisma в качестве ORM

И это всё просто отдельные решения, принятые командой. Мы можем использовать Axios, а можем использовать Got. Мы можем использовать Prisma, а можем использовать TypeORM. Одни решения чуть популярнее других, но все они независимы. Они существуют вне единого зонтика, такого как, например, Spring Framework.

Проще говоря:

В мире Java, если у нас возникает какая-либо проблема, скорее всего, нам НЕ нужно искать решение на GitHub, находить какой-то форк, который делает то, что вам нужно (что, кстати, является распространённой практикой в JavaScript). Почти со стопроцентной вероятностью Spring Framework уже имеет решение для нас.

Почему я рассказываю вам об этом?

Потому что важно понимать, что раз экосистема Java настолько консолидирована вокруг технологического стека Spring Framework, она часто страдает от одних и тех же проблем в продакшене.

Что это за проблемы? Что ж, их довольно много. И мы знаем их все на собственной шкуре:

• У нас течет пул соединений

• Наши API-эндпоинты работают медленно (может, проблема в базе данных?)

• Мы случайно открыли /actuator/env в продакшене и слили секреты

• Наши приложения потребляют слишком много памяти и очень медленно стартуют…

И так далее. И индустрия за десятилетия опыта работы Java в продакшене выработала набор рекомендаций, лучших практик, «решений», гайдлайнов. И эти гайдлайны существуют на разных уровнях приложения, например:

Рекомендации для Hibernate/ORM

• Никогда не используйте EAGER fetch!

• Не используйте CascadeType.ALL или CascadeType.REMOVE для «XToMany»

• Не используйте List для @ManyToMany

• Не используйте однонаправленный @OneToMany!

и так далее. Рекомендации по производительности Spring:

• Отключите OSIV

• Используйте Spring Test Profiler! (инструмент, разработанный Филипом Рикксом - специалистом в области тестирования Spring Boot)

• Используйте умное кэширование контекста Spring! (Сергей Чернов, очень опытный инженер и мой приятель, разработал этот инструмент)!

• Не устанавливайте spring.jpa.show-sql=true или другие опасные свойства в продакшене!

и так далее. Рекомендации даже для нашей любимой Java!

• Используйте Project Leyden!

• Используйте Compact Object Headers (Project Lilliput)

• Настройте логирование GC в продакшене!

И так далее, и так далее. Потому что у нас есть эта консолидированная экосистема, мы в целом знаем, «что правильно, а что неправильно». И долгое время не было такого инструмента, который бы эти гайдлайны собирал вместе.

Но мы посчитали, что это неправильно. И что, вероятно, такой инструмент должен существовать. И этот инструмент называется Axelix (Исходный код).

В версии 1.0.0 мы не поддерживаем обнаружение всех проблем, которые я описал выше (большинства, но не всех). И вышеперечисленное - это лишь пример. Есть огромное количество (действительно, огромное) знаний, которые мы как Java-сообщество накопили за все эти годы и которые мы собираемся вложить в Axelix, чтобы он служил вам верой и правдой.

Надеюсь, к этому моменту мотивация, стоящая за инструментом, ясна, и теперь я хочу ответить на пару вопросов, которые мы уже не раз получали во время выпуска Milestone-версий.

Q: Это бесплатно?

Да, бесплатно. Мы будем следовать модели Open Core. Это модель разработки Open Source ПО, которая лежит в основе проектов, которые мы все любим и ценим:

• Grafana

• Keycloak

• Vaadin

И так далее. Как показывает история, она в целом считается наиболее надёжной моделью для разработки OSS, и именно поэтому лидеры индустрии выбирают её, и именно поэтому мы выбираем её.

Q: Готов ли проект к использованию и развёртыванию?

Да, он готов к бесплатному использованию. Мы обработали отзывы буквально от десятков команд, которые установили Milestone-релизы Axelix и поделились с нами своими наблюдениями.

Q: Безопасно ли развёртывать его в продакшене?

Он спроектирован для продакшена, так что ответ — да. Но поскольку это первый GA-релиз 1.0.0, общая рекомендация — сначала установить его в средах разработки, а затем уже в продакшене.

При этом у нас есть команды, которые уже развернули Axelix в продакшене, чтобы получить представление о поведении своих @Transactional-методов и о разрешении свойств (properties resolution).

Куда мы движемся?

У команды, стоящей за Axelix, много лет опыта в написании и оптимизации Spring Boot-приложений. У нас впереди много работы, и нам ещё предстоит многое включить в Axelix.

Тем, кто хочет узнать, как проект устанавливается и настраивается, пожалуйста, посетите наш сайт, а также нашу документацию (она есть и на английском, и на русском языках).

В случае любых вопросов или трудностей вы всегда можете связаться с командой по адресу: hello@axelix.io Мы, мейнтейнеры, рады ответить на ваши вопросы и помочь вам в процессе установки.

Мы также намерены оставаться приверженными Open Source и нашим ценностям, которые заключаются в том, чтобы ваши Java-приложения были настолько безопасными, производительными и эффективными, насколько это возможно.

Спасибо всем!