Максим Козлов, технический директор GitFlic
Летом 2026 года открытые обновления перестала получать Spring Boot 3.5, последняя версия ветки 3.x. Ветка 2.x лишилась их еще в 2023 году. Для большинства российских компаний это событие прошло незаметно, хотя касается почти каждой корпоративной Java-системы. Мы в GitFlic столкнулись с этим вопросом напрямую и в версии 5.0.0 перевели платформу на российский Java-стек. Расскажу, почему считаю такой путь правильным не только для нас.
Зависимость, о которой вспоминают последней
Spring остается фундаментом корпоративной Java в России. По данным исследования ТехРадар/State of Java 2026 от JUG Ru Group, его используют более 90% опрошенных Java-разработчиков. На Spring Boot 3.x работают 73,1% респондентов, на 2.x 20,4%.
Проблема в том, что жизненный цикл фреймворка заметно короче, чем у систем, построенных на нем. Публичные обновления для промежуточных версий Spring Boot выходят около 13 месяцев. Дальше Broadcom предлагает коммерческую подписку, но российским компаниям она на стандартных условиях недоступна. Банковская система или государственный сервис живут десятилетиями, а их основа устаревает быстрее, чем проходит один цикл закупки.
Два плохих варианта
На практике у компании есть два пути. Первый: мигрировать на каждую новую ветку. Это постоянные затраты, которые не приносят бизнесу новых функций, а на старых версиях Java тянут за собой еще и обновление среды исполнения. Второй: оставаться на неподдерживаемой версии и надеяться, что критическую уязвимость в ней не найдут. Надежда плохая стратегия для системы, через которую проходят деньги или персональные данные.
По данным опроса Axiom JDK, проведенного в августе 2026 года среди более чем 300 специалистов, 32,7% участников одновременно используют несколько поколений Spring Boot. Коммерческую поддержку используют или готовы рассматривать только 26,9%. Значит, большинство компаний пока откладывают решение.
Технический долг становится регуляторным
Для госсектора и регулируемых отраслей устаревший компонент давно перестал быть внутренним делом разработчиков. С 20 декабря 2024 года действует ГОСТ Р 56939-2024 о разработке безопасного ПО, и его требования распространяются на сторонние компоненты продукта. Заказчик вправе спросить вендора, кто выпускает исправления для каждого слоя системы и как собран код. Если ответа нет, вопрос возникает уже не к фреймворку, а к поставщику.
Поэтому разработчикам коммерческого ПО решать проблему придется раньше клиентов. Вместе с продуктом заказчик получает и все его зависимости.
Что мы сделали в GitFlic
DevOps-платформа GitFlic изначально написана на Java и Spring, это собственный код, а не форк GitLab. Конец открытой поддержки Spring для нас касается ядра продукта, а не одной библиотеки. Мы выбирали между постоянной гонкой за новыми ветками и сменой поставщика поддержки.
В GitFlic 5.0.0 мы заменили Spring Framework на Axiom Spring, а Apache Tomcat на сервер приложений Libercat. Axiom Spring обеспечивает долгосрочную поддержку Spring Framework 5.x и 6.x, Spring Boot 2.7.x до 2029 года (в рамках premier support дольше) и 3.5.х до 2032 года и собирается по процессу безопасной разработки. Патчи безопасности выходят регулярно, а срочно мигрировать на новую ветку не нужно.
Для заказчиков GitFlic результат простой: платформа работает в сертифицированной ФСТЭК Java-среде российского производства, не зависит от зарубежных поставщиков и обслуживается на русском языке. Компаниям из госсектора и регулируемых отраслей стало проще внедрять GitFlic: вопрос происхождения Java-стека больше не требует оговорок.
Суверенитет без изоляции
Здесь важно подчеркнуть одну деталь. Мы не переписывали платформу на новый экзотический фреймворк. Команда осталась на тех же версиях Spring, сохранила компетенции и привычные инструменты, но исправления теперь приходят от российского поставщика.
Это и есть зрелая модель импортозамещения. Полная изоляция от мирового open source тормозит разработку: отказываться от технологий, на которых выросла целая инженерная школа, бессмысленно. Риск создает не сам открытый код, а зависимость от поставщика, который может в любой момент закрыть доступ к обновлениям. Этот риск и нужно убирать.
Коллегам-техническим директорам я бы советовал начать с простого: составить карту зависимостей, посмотреть, у каких компонентов закончилась или скоро закончится поддержка, и заранее решить, кто будет их обслуживать. Сделать это лучше до того, как вопрос задаст заказчик или регулятор.
Реклама: ООО «РеСолют», ИНН: 9704054697
