Итак, в конце 2025 вышел Spring Boot 4 и Spring Framework 7. InfoQ взяли интервью у core команды Spring с целью узнать, куда движется самая популярная в Java экосистема.

Spring Boot 4 модуляризировал автоконфигурацию. Теперь при запуске проверяется меньше классов в classpath, а uber-jar будет более компактным: будут подключаться только нужные модули. Параллельно Spring Boot 4 переходит на Jackson 3, но добавлен модуль совместимости с Jackson 2, потому что экосистема ещё догоняет.

Spring Framework 7 тащит core resilience в ядро: RetryTemplate, @Retryable и @ConcurrencyLimit доступны без отдельной зависимости. @Retryable работает и с реактивными типами (через Retry из Project Reactor); для обычных вызовов используется RetryTemplate с политикой retry/backoff. @ConcurrencyLimit помогает ограничивать доступ к ресурсу, что особенно полезно с Virtual Threads.

Особое внимание команда Spring уделила AI Agent-ам и потенциальной поддержке тулинга для AI Agent-ов в рамках проекта Spring Tools.

Ключевые выводы

• Модульность Spring Boot 4 улучшает время запуска за счёт сокращения проверок осуществляемых в classpath для классов авто-конфигурации и создания более компактных uber-jar, хотя производительность не была основным мотивом этих изменений.

• Spring Framework 7 интегрирует повторные попытки (retry) и ограничение конкуррентности непосредственно в ядро фреймворка, благодаря чему такие возможности, как RetryTemplate, @Retryable и @ConcurrencyLimit, доступны без дополнительных зависимостей.

• Учитывая большое разнообразие HTTP-серверов и клиентских стеков, пользователям нужно выбрать подходящую стратегию версионирования HTTP API в Spring Framework 7 под свою ситуацию — например, через путь, заголовок, параметр запроса или параметр media type.

• Часть участников команды Spring считает инструменты ИИ-кодинга трансформирующими разработку, и команда Spring активно исследует, как предоставлять ИИ-ассистентам специфический для Spring контекст.

• Переход со Spring Boot 3 на 4 должен быть управляемым для типичных приложений — этому помогают модуль совместимости с Jackson 2, руководство по миграции и рецепты OpenRewrite от сообщества, хотя Spring Boot 3.5 получит последний бесплатный релиз в июне 2026 года.

Введение

Broadcom выпустила Spring Framework 7.0 и Spring Boot 4.0 (анонсировано здесь и здесь) в ноябре 2025 года. Это новое поколение приносит поддержку версионирования REST API на first-class уровне, аннотации JSpecify для стандартизированной null-безопасности по всему портфелю Spring, а также встроенные механизмы устойчивости, включая повторные попытки и ограничение конкуррентности. Spring Boot 4 переходит на Jackson 3 для обработки JSON и разделяет монолитный autoconfigure-JAR на модули. Spring Framework 7 сохраняет бейзлайн JDK 17, одновременно поддерживая версии JDK вплоть до 25, но обновляет базовые зависимости до Jakarta EE 11 и Kotlin 2.2.

После релиза Spring Boot 4 ряд проектов Spring также выпустил крупные обновления: Spring Cloud, Spring Modulith и Spring Shell. Ожидается, что Spring Boot 4.1 выйдет в мае 2026 года.

Недавно InfoQ поговорил с ключевыми участниками команды Spring в Broadcom о значимых архитектурных и функциональных улучшениях в Spring Framework 7 и Spring Boot 4. Разговор охватывает стратегический поворот в сторону «core resilience» — интеграцию таких возможностей, как retry и ограничение конкуррентности, прямо в фреймворк, а также выигрыш по производительности от модульной авто-конфигурации.

Участники также обсуждают реализацию поддержки версионирования HTTP API «первого класса» и трансформирующую роль инструментов ИИ-кодинга в современном рабочем процессе разработчика. Наконец, команда даёт практические рекомендации по апгрейду со Spring Boot 3 на 4, выделяя конкретные инструменты, модули совместимости и ресурсы сообщества, которые упрощают переход для корпоративных приложений.

Участники панели

• Фил Уэбб, со-создатель и руководитель Spring Boot

• Сэм Брэннен, коммиттер ядра Spring Framework и мейнтейнер JUnit

• Росен Стоянчев, коммиттер Spring Framework: Spring MVC, WebFlux

• Марк Поллак, основатель проекта Spring AI

• Мартин Липперт, руководитель проектов Spring Tools

• Майкл Минелла, директор команды Spring R&D по open source, бывший руководитель Spring Batch

InfoQ: Каков реальный эффект для производительности от модульности авто-конфигураций в Spring Boot 4? И как, по-вашему, это повлияет на разработку сторонних starter’ов?

Фил Уэбб: Производительность не была основной причиной работы по модульности, однако, думаю, мы увидим улучшения во времени запуска. Многие классы авто-конфигурации активируются только тогда, когда в classpath найден определённый класс. В более ранних версиях Spring Boot нам приходилось проверять множество классов при каждом запуске приложения. Модульность означает, что проверять придётся меньше.

Ещё один небольшой плюс для производительности связан с размером uber-jar, который вы собираете. Если брать только нужные модули, jar получается меньше. Это означает, что нужно прочитать меньше байтов.

InfoQ: Почему вы решили интегрировать Spring Retry в Spring Framework, а не сохранить его модульным?

Сэм Брэннен: «Core resilience» — одна из главных тем Spring Framework 7, и под этим зонтом мы вводим как поддержку повторных попыток, так и аннотационно-управляемое ограничение конкуррентности.

Исторически сообщество Spring опиралось на проект Spring Retry для разных вариантов retry. Однако для седьмого поколения фреймворка мы решили включить базовую поддержку повторных попыток на самом высоком уровне — интегрировать  прямо в Spring Framework. Хотя эта поддержка, естественно, вдохновлена Spring Retry, мы полностью переработали её как минимальный набор core-возможностей в модулях  spring-core и spring-context. Это позволяет всем разработчикам Spring использовать RetryTemplate и @Retryable без необходимости подключать дополнительную зависимость. Иными словами, базовый retry доступен всегда, и даже сам Spring Framework может естественно опираться на эти возможности — например, в RestClient.

Если говорить о функциональности, RetryTemplate позволяет разработчикам внедрять программный retry прямо в код, полностью контролируя политику повторов и стратегию backoff. В то время как @Retryable поддерживает декларативный подход: разработчик помечает класс или метод аннотацией @Retryable и задаёт настройки повторов и backoff через атрибуты аннотации. @Retryable естественным образом поддерживает императивные модели программирования; однако, в отличие от поддержки в проекте Spring Retry, аннотация @Retryable в Spring Framework может применяться и к методам с реактивными типами возвращаемых значений. Spring «оборачивает» реактивный pipeline спецификацией Retry из Project Reactor. Для нереактивных типов Spring просто настраивает RetryPolicy и делегирует выполнение RetryTemplate.

И, наконец, @ConcurrencyLimit позволяет разработчикам задавать лимит конкуррентности для конкретного вызова метода. Такое ограничение фактически защищает целевой ресурс от доступа слишком большого числа потоков одновременно — эффект похож на ограничение размера пула в Thread Pool или Connection Pool, который блокирует доступ при достижении лимита. Это особенно полезно с Virtual Threads, где обычно нет ограничения на уровне пула потоков.

InfoQ: В Spring Framework 7 версионирование API реализовано через HTTP-заголовки. Какие у вас планы по взаимодействию с другими сообществами — JavaScript, Python, .NET, — чтобы этим версиями было удобно пользоваться и там?

Росен Стоянчев: Серверное приложение на Spring Framework 7 может выбрать из набора стратегий версионирования API: через путь, заголовок, параметр запроса или через media type. Выбор зависит от ряда соображений.

Ключевой фактор — глубина ожидаемых изменений. Например, версионирование через путь может вместить более глубокие структурные изменения в доменной модели. Версии через заголовок и параметр запроса удобны, когда ожидаются более «лёгкие» изменения, и позволяют версионировать маппинги контроллеров инкрементально, по мере необходимости.

Ещё один фактор — существование разных руководств по REST API. Например, если нужно или принято следовать Microsoft REST API guidelines, вы выберете между версией в пути вроде v1.0 или параметром запроса с именем api-version. Но если вы следуете Zalando RESTful API guidelines, вы используете параметр version в Media Type.

Учитывая широкий выбор и разные практики, Spring Boot не принимает готовых решений «из коробки». Приложения должны явно включить версионирование API и одновременно выбрать стратегию версионирования, а также другие детали — например, имя заголовка или параметра запроса, формат версии (семантический vs по дате) и т. д. Решение остаётся за разработчиком.

С самого начала, когда мы решили добавить поддержку версионирования API, мы понимали, что это тонкая область с множеством мнений и без универсального решения. Поэтому вместо того чтобы навязывать или направлять к определённому набору вариантов, мы хотели дать строительные блоки, которые расширяют возможности разработчиков и поддерживают их при любом выборе.

С точки зрения клиента нужно следовать ожиданиям сервера. Например, если вы пишете клиент к REST API GitHub, вам понадобится заголовок X-GitHub-Api-Version. В этом смысле детали стратегии меньше связаны с технологией реализации и больше — с конкретными решениями по дизайну REST API в приложении.

Билдеры для RestClient и WebClient позволяют настроить версионирование API один раз, чтобы при отправке запросов прикладной код не занимался деталями HTTP-запросов. Аналогично, аннотация @HttpExchange для HTTP-интерфейсных клиентов теперь поддерживает атрибут version и отделена от деталей HTTP-запроса: их можно задать в конфигурации без изменения кода доступа к запросам. Ожидается, что библиотеки клиентов на JavaScript, Python, .NET и других платформах предоставят похожие возможности и настраиваемость.

InfoQ: Каков ваш опыт работы с ИИ-инструментами для кодинга вроде Claude Code, GitHub Copilot или Google Gemini на проектах Spring? Как, по-вашему, изменится работа Spring-разработчика с появлением этих инструментов?

Марк Поллак: Мой опыт был трансформирующим. Я не думаю, что разработчики любого профиля будут писать код так же, как мы делали это последние 20 лет. Для разработчиков, которые уже опытны и обладают хорошими навыками проектирования, взаимодействие с современными инструментами кодинга меняет правила игры. Понадобится время, чтобы увидеть, какие разработчики научатся использовать эти инструменты эффективно. Так что я довольно оптимистично настроен относительно того, насколько они трансформируют процесс написания кода. Другие не согласны, особенно те, кто любит задавать ИИ вопрос «сколько букв R в слове Strawberry» и получать удовольствие, наблюдая ошибки в ответе на single-shot prompt, но в целом таков мой личный опыт.

InfoQ: Файлы с подробными правилами, руководствами и best practices могут направлять ИИ-инструменты к тому, чтобы они писали для нас более качественный код. Для Claude Code, например, такие файлы могут быть skills или subagents. Планируете ли вы публиковать подобные файлы? Например, проект-специфичные — для Spring Web MVC или Spring Data — или горизонтальные, скажем, по безопасности или производительности.

Мартин Липперт: Это действительно интересная тема, и мы активно изучаем её — и с точки зрения того, что могли бы сделать напрямую, и с точки зрения партнёрств, — но на данный момент всё находится на исследовательской стадии. Предстоящий релиз Spring Tools 5 станет первым поколением Spring Tools, например, которое будет готово к AI-coding-окружениям и будет включать возможности предоставлять ассистенту вокруг вас более глубокие Spring-инсайты по проектам в вашем workspace. Что мы будем делать дальше — пока не решено.

InfoQ: Spring Boot 4 создаёт сложности при обновлении для многих разработчиков — включая новые имена пакетов в Jackson 3 и аннотации nullability JSpecify. Какие инструменты или ИИ-поддержка доступны разработчикам для обновления приложений Spring Boot 3?

Фил Уэбб: Нам очень повезло с активным сообществом разработчиков, которое попробовало ранние milestone-версии и дало отличную обратную связь. Это помогло нам уточнить некоторые решения, чтобы облегчить жизнь тем, кто обновляется. Например, мы добавили модуль Jackson 2, потому что знаем: большая часть экосистемы ещё не перешла на Jackson 3.

Мы также обновляли собственные внутренние приложения, чтобы почувствовать, насколько болезненным будет переход. И были приятно удивлены: многие типичные приложения на Spring Boot можно обновить без чрезмерных усилий. Например, множество переименований пакетов затрагивает классы авто-конфигурации, которые пользователи обычно не импортируют напрямую. Мы также внимательно отнеслись к поддержке переименованных configuration properties — чтобы IDE и jar-модуль мигратора свойств помогали быстро находить замены.

Разработчикам, которые планируют обновление, стоит начать с руководства по миграции на нашей wiki. Мы также ожидаем, что сообщество может подключиться и предоставить рецепты OpenRewrite для типичных проблем миграции — как это уже бывало раньше. Клиенты, которые приобрели поддержку у Broadcom, также могут воспользоваться инструментом Application Advisor.

Конечно, ни одно крупное обновление не бывает полностью безболезненным. Мы ожидаем, что пользователям с более глубокими интеграциями Spring Boot придётся потратить на апгрейд немного больше времени, чем владельцам обычных приложений.

InfoQ: В Spring Boot 2.7 после выхода Spring Boot 3 оставалось ещё 12 месяцев бесплатных релизов сопровождения, после чего следовали ещё 37 месяцев платных релизов. У Spring Boot 3.5 сейчас осталось ещё месяц бесплатных релизов сопровождения — до июня 2026 года — после чего последуют ещё 72 месяца платных релизов. Как, по-вашему, это повлияет на корпоративное принятие Spring Boot 4?

Майкл Минелла: По тому, как мы взаимодействовали с пользователями, несколько месяцев open-source-поддержки в ту или иную сторону, как правило, не меняют для них картину, когда речь идёт о сроках обновления. Сообщество знает о грядущих мажорных версиях уже больше года, и те, кто предпочитает оставаться на версиях, поддерживаемых в рамках open source, были вовлечены всё это время. Чтобы дать пользователям возможность подключаться как можно раньше, в этот цикл мы впервые начали публиковать milestones и release candidates в Maven Central, что привело к заметному росту обратной связи и позволило нам дополнительно «отполировать» релизы.

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

Мы понимаем все эти сценарии. Хотя мы твёрдо убеждены, что для пользователей лучше всего оставаться на актуальных релизах (и предоставляем для этого инструменты, включая Application Advisor), мы выстроили предложения по поддержке так, чтобы были возможны все варианты, потому что не каждое приложение требует одинакового уровня инвестиций.

Выводы

Spring Boot 4 приносит модульные авто-конфигурации, которые должны улучшить время запуска за счёт сокращения проверок classpath, а также более компактные uber jar-ы. Spring Framework 7 добавляет встроенную поддержку повторных попыток через RetryTemplate и @Retryable — включая реактивные типы возвращаемых значений — а также @ConcurrencyLimit для ограничения конкуррентности, что особенно полезно с Virtual Threads. Версионирование API поддерживает стратегии через путь, заголовок, параметр запроса и media type, при этом Spring Boot не навязывает вариант «по умолчанию». Команда Spring считает инструменты ИИ-кодинга трансформирующими и планирует выпустить Spring Tools 5 с функциями, готовыми для AI-сред, хотя более широкие «гайд-файлы» для ИИ пока остаются на исследовательской стадии.

При обновлении до Spring Boot 4 команда ожидает, что большинство типичных приложений мигрируют с разумными усилиями. Модуль совместимости с Jackson 2 упрощает переход на Jackson 3, а инструменты в IDE помогают с переименованными configuration properties. Лучшее место, с которого стоит начать, — руководство по миграции на Wiki; рецепты OpenRewrite от сообщества могут автоматизировать большую часть перехода. Клиенты Broadcom с поддержкой также могут использовать инструмент Application Advisor.

Что касается сроков поддержки, команда Spring отмечает, что сокращённое окно бесплатной open-source-поддержки Spring Boot 3.5 (7 месяцев после релиза Spring Boot 4) для большинства пользователей не оказало заметного влияния на сроки обновления. Зато расширенная корпоративная поддержка — теперь 72 месяца платных релизов — даёт организациям гибкость: обновляться в удобном темпе или поддерживать приложения, которые планируется вывести из эксплуатации.

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.