Spring Boot 4: обзор нового релиза

Оглавление

1. Введение
2. Обновление базовых зависимостей и требований
3. Модульный дизайн и изменения в автоконфигурации
4. Поддержка новых версий Java и технологий
5. Новые возможности и улучшения Spring Boot 4
6. Таблица основных изменений
7. Рекомендации по миграции с Spring Boot 3.x на 4.0.0-M1
8. Заключение

Введение

Фреймворк Spring Boot уже много лет занимает лидирующие позиции среди инструментов для разработки backend-приложений на Java. С каждым крупным релизом он не только следует актуальным трендам разработки, но и сам задает их направление, облегчая работу тысячам разработчиков по всему миру. Выпуск первой milestone-версии Spring Boot 4.0.0-M1 не стал исключением – он знаменует собой важные архитектурные изменения и серьезные обновления, которые существенно влияют на то, как мы создаем современные приложения.

В новой версии фреймворка Spring Boot команда разработки сделала ставку на модульность, улучшенную поддержку последних спецификаций Jakarta EE 11, интеграцию современных возможностей платформы Java (таких, как виртуальные потоки Project Loom и native-компиляция с GraalVM), а также обновление основных зависимостей до актуальных версий. Все это призвано упростить разработку, повысить производительность и обеспечить максимальную совместимость приложений с новыми стандартами и практиками индустрии.

Обновление базовых зависимостей и требований

Spring Boot 4.0 построен на новейших версиях экосистемы Spring и сторонних проектов. В частности, минимальной версией Spring Framework теперь является Spring Framework 7.0 (в сборке M7 на момент данного релиза). Это означает поддержку актуальных спецификаций Jakarta EE 11 (например, Servlet 6.1, Jakarta Persistence 3.2, Jakarta Validation 3.1 и др.) и соответствующих контейнеров и ORM-фреймворков. В состав Spring Boot 4 вошли новые мажорные версии Spring-проектов, среди которых: Spring Data 2025.1, Spring Security 7.0, Spring Integration 7.0, Spring Batch 6.0, Spring Authorization Server 2.0 и другие.

Модульный дизайн и изменения в автоконфигурации

Одно из крупнейших архитектурных изменений в Spring Boot 4 – переход к модульному дизайну. Команда Spring Boot провела рефакторинг кодовой базы, разбив монолитные артефакты автоконфигурации на более мелкие, тематические модули. Если ранее большая часть автоматической конфигурации поставлялась в одном крупном JAR (spring-boot-autoconfigure), то теперь она разделена по функциональным областям. Например, появились отдельные артефакты spring-boot-webmvc, spring-boot-data-jpa, spring-boot-security и т.д., каждый из которых отвечает за автоконфигурацию своего компонента или технологии.

Для разработчиков, использующих стартеры Spring Boot, переход на модульную архитектуру пройдет практически прозрачно – актуальные стартеры уже подтягивают необходимые модульные зависимости, и приложение продолжит работать без изменений. Однако, если в проекте явно указывались зависимости на автоконфигурацию или использовались технологии без официальных стартеров, может потребоваться вручную добавить новые артефакты. В документации приведена таблица соответствия технологий и новых модулей Spring Boot 4.0 (см. пример ниже). В большинстве случаев достаточно подключить соответствующий starter; для более тонкого контроля – указать напрямую нужный модуль (например, spring-boot-jdbc вместо прежнего импорта всей автоконфигурации JDBC).

Изменения в автоконфигурации затронули и наименования некоторых классов. В частности, для согласованности были переименованы несколько автоконфигурационных классов в реактивном стекe Spring (WebFlux и др.). Это важно учесть при миграции, особенно если в приложении явно исключались (exclude) или переопределялись конкретные автоконфигурационные классы – их именования могло измениться. Рекомендуется ознакомиться со списком изменений конфигурации (Configuration Changelog) для выявления устаревших имен и свойств.

В контексте модульности появилась возможность описывать метаданные конфигурации, распределенные по разным модулям. Теперь классы с аннотацией @ConfigurationProperties могут ссылаться на типы из других модулей, и при этом для корректной генерации метаданных используется новая аннотация @ConfigurationPropertiesSource. Пометив ею внешний тип (который находится в отдельном модуле), можно обеспечить включение его параметров в конфигурационные метаданные вашего приложения. Это особенно полезно в больших системах, где конфигурационные POJO разделены по модулям: благодаря @ConfigurationPropertiesSource IDE и Spring Boot Configuration Processor будут видеть полный набор свойств, доступных для настройки.

Поддержка новых версий Java и технологий

Spring Boot 4 ориентирован на современные стандарты Java. Хотя формально минимальная версия остается Java 17, фреймворк полностью поддерживает Java 21 и связанные с ней возможности. В частности, Spring Boot еще в версии 3.2 добавил поддержку виртуальных потоков (Virtual Threads, проект Loom), и новый Boot 4 продолжает развивать эту интеграцию. Виртуальные потоки позволяют облегчить масштабирование высоконагруженных приложений, используя легкие потоки вместо традиционных платформенных. В Spring Boot 4 достаточно запустить приложение под Java 21 и установить свойство конфигурации spring.threads.virtual.enabled=true, чтобы переключить выполнение запросов на виртуальные потоки. При активированной опции встроенные серверы (Tomcat, Jetty) начинают обслуживать HTTP-запросы на виртуальных потоках, так что, например, методы контроллеров будут выполняться уже не в стандартном Thread-пуле, а во виртуальных потоках. Это происходит прозрачно для разработчика – вы можете писать код как обычно, но потенциал параллелизма станет выше при том же потреблении ресурсов.

Вот простой пример использования виртуальных потоков в веб-приложении на Spring Boot 4:

# application.properties
spring.threads.virtual.enabled=true 

@RestController
class DemoController {

    // При включенных виртуальных потоках этот запрос выполняется на virtual thread
    @GetMapping("/data")
    public String getData() {
        // Выполнение длительной операции не блокирует платформенные потоки
        heavyService.callExternalAPI(); 
        return "OK";
    }
}

В приведенном примере при запросе к /data длительная операция callExternalAPI() выполняется во виртуальном потоке, что позволяет обрабатывать большое количество таких запросов параллельно без вытеснения потоков ОС. При этом программисту не пришлось переписывать код на реактивный стиль – взаимодействие с Loom встроено под капотом Spring Boot. Отметим, что виртуальные потоки влияют и на другие подсистемы: при их включении Spring Boot автоматически настраивает SimpleAsyncTaskExecutor на использование виртуальных потоков для заданий @Async, а также переключает слушателей сообщений Kafka и RabbitMQ на виртуальные потоки и т.д.. Таким образом, новая модель потоков пронизывает большинство компонентов, не требуя явных изменений в коде приложения.

Кроме Loom, Spring Boot 4 учитывает и другие эволюционные изменения Java. Например, платформа готова к грядущим релизам JDK (в сообществе Spring заявлено о намерении поддержать Java 25 LTS на момент выхода финальной версии Spring Boot 4.0). Также в кодовой базе Spring Framework 7 и Boot 4 уделяется внимание статическому анализу и null-безопасности: применяются аннотации JSpecify для пометки nullable/non-null контрактов. Это улучшает опыт разработчиков, особенно при использовании Kotlin, хотя внешне на API приложения не влияет.

Новые возможности и улучшения Spring Boot 4

Помимо фундаментальных изменений, в Spring Boot 4.0.0-M1 представлено множество мелких и крупных улучшений, упрощающих разработку и повышающих производительность приложений:

• Улучшения безопасности и OAuth 2. Благодаря обновлению Spring Security до версии 7 и интеграции Spring Authorization Server 2.0, Spring Boot 4 готов к новшествам в области безопасности. Spring Security 7 привносит обновления к OAuth 2.1, OpenID Connect и ряду политики безопасности. Spring Authorization Server 2.0 (автоконфигурируемый через стартер spring-boot-starter-security-oauth2-authorization-server) стал более зрелым – если вы строите собственный OAuth2 Authorization Server, этот модуль теперь официально поддерживается. В существующих проектах на Spring Boot 3.x миграция на Security 7 обычно несложна, но требует проверить конфигурации: например, могли измениться некоторые свойства или методы API безопасности. Рекомендуется ознакомиться с миграционным гидом Spring Security 7 при обновлении.
• Прочие улучшения. Среди прочих полезных изменений можно отметить:
  • Изменена логика проверки SSL-сертификатов в Actuator: больше не используется статус WILL_EXPIRE_SOON для сертификатов, срок действия которых подходит к концу. Вместо этого в метрике здоровья SSL теперь просто указывается статус VALID, а подробности о скором истечении сертификата выносятся в отдельное поле expiringChains с перечислением цепочек сертификатов, у которых истекает срок. Если в ваших дашбордах или скриптах мониторинга использовался статус WILL_EXPIRE_SOON, их надо обновить – теперь критерий просрочки сертификата придется определять по наличию записи об expiringChains.
  • Улучшенные сообщения об ошибках конфигурации. В случае, когда биндинг свойств из конфигурации проваливается из-за отсутствия нужного класса (ClassNotFound), Spring Boot 4 выдает более понятное сообщение об ошибке. Это облегчает отладку неправильных настроек, указывая прямо на проблему с зависимостями или опечаткой в имени класса.
  • Поддержка Testcontainers для MongoDB Atlas: аннотация @ServiceConnection в Spring Boot 4 научилась распознавать специальный контейнер MongoDB Atlas Local из Testcontainers для интеграционного тестирования. Это расширяет возможности написания тестов с аннотацией @DynamicPropertySource – подключение к эмуляции Atlas теперь так же просто, как и к локальному MongoDB.
  • Обновлены версии Kotlin (до 2.2), Gradle, Mockito, OpenTelemetry и множества иных библиотек. Хотя эти обновления могут показаться минорными, они вместе дают улучшения производительности и совместимости с новыми версиями инструментов.

Таблица основных изменений

Ниже сведены ключевые изменения Spring Boot 4.0.0-M1 с кратким описанием и влиянием на существующие приложения:

Изменение	Описание	Влияние на проекты 3.x
Модульный дизайн автоконфигурации	Разбиение spring-boot-autoconfigure на десятки небольших модулей, каждый отвечает за конкретную технологию (Web, Data JPA, Security и т.д.). Стартеры обновлены под новые артефакты.	Требуется проверить зависимости: приложения на старых стартерах обычно подтянут всё автоматически, но при нестандартной конфигурации может понадобиться явно добавить новые модули. Исключения автоконфигураций по имени нужно обновить с учётом возможных переименований классов.
Требования к Java и поддержка новых возможностей	Минимальная версия Java осталась 17, рекомендована Java 21 (LTS) или выше. Spring Boot 4 полностью поддерживает виртуальные потоки (Project Loom) из Java 21 для обработки запросов и задач. Продолжается поддержка быстрого старта через Checkpoint/Restore (проект CRaC).	Приложения на Java 17 продолжат работать. Для использования виртуальных потоков достаточно запустить на JDK 21 и включить флаг spring.threads.virtual.enabled=true. Эффект – потенциально лучше масштабируемость без переписывания кода под Reactor. Функциональность CRaC (снимки состояния JVM) доступна экспериментально – при миграции можно начинать её пробовать для сокращения времени холодного старта сервисов.
SSL Health Indicator упрощён	Метрики Actuator для SSL-сертификатов больше не используют статус WILL_EXPIRE_SOON. Вместо этого сертификаты либо VALID, либо EXPIRED, а приближение истечения отражается через подробности (expiringChains).	Мониторинги, которые опирались на статус WILL_EXPIRE_SOON, нужно обновить. Теперь для выявления «скоро истекающих» сертификатов придётся анализировать дату истечения из деталей или вручную сравнивать с порогом (management.health.ssl.certificate-validity-warning-threshold). В целом, здоровье SSL стало проще, но логика оповещений о скором истечении – на стороне пользователя.
Обновления в сфере безопасности	Spring Security 7 и смежные проекты привнесли изменения в конфигурации. Некоторые свойства в application.properties могли измениться (например, настройки SameSite cookie или CSRF). Authorization Server 2.0 M1 поддерживает новые RFC и упрощает настройку OAuth2 Authorization Server.	Перед миграцией рекомендуется изучить Release Notes Spring Security 7.0. При обновлении убедитесь, что ваш код не использует убранные методы (несколько устаревших констант и конфигурационных API могли быть удалены). Конфигурационные YAML/Properties для security следует сравнить с документацией 4.0 – возможно, потребуются правки.
Прочие изменения	Множество минорных улучшений: обновление шаблонизаторов (Thymeleaf, Freemarker), поддержка новых версий БД и драйверов.	В большинстве случаев эти изменения не ломают совместимость. Однако рекомендуется просмотреть официальные Release Notes и Migration Guide: там перечислены все снятые с поддержки параметры и классы. Например, прекращена поддержка Jetty 11 (нужно обновиться до Jetty 12), а Launch-script loader в Spring Boot получил обновлённый формат URL (обычно прозрачно, но при прямом использовании PropertiesLauncher есть нюансы). Внимательно протестируйте сборку и запуск после миграции.

Рекомендации по миграции с Spring Boot 3.x на 4.0.0-M1

Поскольку Spring Boot 4.0 пока находится в статусе Milestone (предварительная версия), миграцию следует планировать осторожно. Вот основные рекомендации для перехода с 3.x (например, 3.5) на 4.0.0-M1:

1. Обновитесь до последней версии 3.5.x перед миграцией. Разработчики настоятельно советуют сначала поднять проект до актуального релиза Spring Boot 3.5, так как в нем уже учтены многие подготовительные изменения. Версия 3.5 содержит последние патчи и, возможно, предупреждения о депрекейтах, которые важно устранить до перехода.
2. Проверьте использование устаревших API. Все элементы, помеченные как @Deprecated в линейке 3.x, были удалены в Spring Boot 4. Это касается как методов Spring Boot (например, старых методов SecurityFilterChain, устаревших конфигурационных свойств), так и связанных проектов (Spring Data, etc.). Просмотрите логи при сборке на 3.5 – если там есть предупреждения о депрекейтах, исправьте их заранее. Например, в Actuator были помечены устаревшими некоторые конструкторы OperationMethod – в Boot 4 их больше нет. Аналогично, убедитесь, что не остались неиспользуемые старые свойства application.properties – некоторые могли исчезнуть или переехать.
3. Сравните версии зависимостей. Переход на Spring Boot 4 подтянет новые версии множества библиотек. Ознакомьтесь с таблицей dependency management: сравните, какие версии Hibernate, Tomcat, Flyway, Kafka и т.д. были в Spring Boot 3.5 и какие стали в 4.0. Если вы явно переопределяли версии этих зависимостей в Maven/Gradle, пересмотрите необходимость – возможно, стоит довериться bom Spring Boot 4, либо обновить ваши версии до новых. Учтите, что некоторые старые библиотеки могут быть несовместимы: например, если приложение работало с устаревшим драйвером базы данных, он может не работать с Hibernate 7 (потребуется обновить драйвер).
4. Модульные артефакты и стартеры. После обновления версии Spring Boot в вашем build.gradle или pom.xml, внимательно изучите собранный набор зависимостей. Если ваше приложение подключало какой-то Spring-проект без стартера, либо вы видите ошибку “No auto-configuration classes found for …”, это симптом, что нужно добавить нужный модуль. Воспользуйтесь официальной таблицей соответствия (как частично приведено выше) или документацией Spring Boot 4, чтобы найти нужный артефакт для вашей технологии. Например, раньше для интеграции с ElasticSearch достаточно было иметь spring-boot-starter-data-elasticsearch, теперь же может потребоваться добавить spring-boot-elasticsearch (новый модуль автоконфигурации). В логах приложения Spring Boot при старте обычно пишет, какие автоконфигурации активирует, а какие пропускает – это поможет понять, все ли подтянулось.
5. Проверьте конфигурационные свойства. Изучите “Configuration Changelog” для Spring Boot 4.0. Некоторые ключи в application.properties могли измениться или удалиться. Например, если вы настраивали Jetty 11 в Boot 3, то в Boot 4 Jetty 11 больше не поддерживается – нужно перейти на Jetty 12 и, возможно, обновить свойства, связанные с сервером. Другой пример: свойства, относящиеся к SSL-показателям Actuator, изменились из-за упрощения статусов. После миграции запустите приложение с профилем, близким к продакшен-конфигурации, и просмотрите лог – Spring Boot выводит предупреждения о неизвестных параметрах конфигурации, что укажет на устаревшие настройки.
6. Тестирование и Gradle/Maven плагины. Пересоберите приложение и прогоните все тесты. Обратите внимание на интеграционные тесты: возможно, понадобятся правки, если вы использовали специфичные API, измененные в Boot 4 (например, для тестирования Security или загрузки контекста). Обновите плагины Spring Boot для Gradle/Maven до 4.0.0-M1 версии – они тоже обновлены. Проверьте сборку контейнеров (если используете Spring Boot Docker support): в Boot 3.2 поменялись дефолтные builder image, а в Boot 4 могут еще раз обновиться – удостоверьтесь, что собираемый образ работает. Если что-то идет не так, флаг loaderImplementation=CLASSIC может временно помочь использовать старый загрузчик jar (см. примечание по PropertiesLauncher), но в идеале лучше устранить причины проблемы.
7. Оцените миграцию Gradle 8/Kotlin. Если вы пишете конфигурацию на Kotlin DSL или используете Kotlin-код, помните, что Spring Boot 4 переходит на Kotlin 2.2, а Gradle – на 8.x версию. Убедитесь, что синтаксис плагинов и скриптов совместим. Kotlin 2.2 приносит улучшения в null-типизации, что хорошо сочетается с JSpecify аннотациями в Spring – возможно, ваш Kotlin-код станет безопаснее при обнулении.
8. Следите за обновлениями документации. Поскольку 4.0.0-M1 – это предварительный выпуск, документация может быть еще не полностью скорректирована. Команда Spring Boot ведет Migration Guide (пока черновой), где фиксируются все важные изменения. Перед финальным релизом 4.0 эти материалы обновятся. Рекомендуется регулярно проверять официальный Spring Blog на предмет статей о Spring Boot 4 – там могут появиться советы и разборы перехода, когда больше пользователей попробуют M1 и найдут потенциальные подводные камни.

Миграция на Spring Boot 4.0 – значительный шаг, но он открывает доступ к новым возможностям платформы и будущим обновлениям Java. Планируя переход, закладывайте время на тестирование и поэтапное внедрение. Уже сейчас можно экспериментировать с Spring Boot 4.0.0-M1, получая опыт работы с модульной архитектурой и новыми API. Команда Spring призывает сообщество пробовать ранние версии и сообщать об ощутимых проблемах, чтобы к финальному выпуску (планируется в конце 2025 года) сделать переход максимально плавным.

Заключение

Выход Spring Boot 4.0.0-M1 является значимым этапом развития экосистемы Spring и открывает широкие возможности для backend-разработчиков. Благодаря переходу на новую модульную архитектуру, интеграции последних версий Java и спецификаций Jakarta EE 11, улучшениям в производительности и поддержке виртуальных потоков Project Loom, фреймворк продолжает укреплять свою позицию лидера в области разработки современных Java-приложений.

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