Что нового в Spring Framework 6.2, Spring Boot 3.4 и каковы планы на будущее?

Команда Spring АйО перевела статью InfoQ, посвящённую новым версиям Spring Framework и Spring Boot. В статье обсуждаются улучшения последних релизов, анонс следующего поколения Spring, запланированного на 2025 год, а также ответы на вопросы редакции InfoQ от руководителя проекта Spring Framework Юргена Хёллера и контрибьютера Spring Framework core Себастьяна Делюза.

В ноябре 2024 года компания Broadcom выпустила Spring Framework 6.2 и Spring Boot 3.4, основываясь на Java 17 и Jakarta EE 9. Spring Boot 3.4 предлагает структурное логирование, добавляет контейнерные images для Docker Compose и Testcontainers, а также улучшает сборку контейнерных images и работу актуаторов. Broadcom также объявила о выпуске Spring Framework 7 и Spring Boot 4 в ноябре 2025 года. Новые версии сохранят поддержку Java 17, но перейдут на Jakarta EE 11, внедрят JSpecify для обеспечения null-safety подхода, и ускорят запуск приложений благодаря Project Leyden. InfoQ обсудил эти релизы 2025 года с руководителем проекта Spring Framework Юргеном Хёллером (Juergen Hoeller) и коммитером Spring Framework core Себастьяном Делюзом (Sébastien Deleuze).

Структурное логирование обеспечивает формат вывода логов с четко определенной, зачастую машиночитаемой структурой. Spring Boot поддерживает форматы Elastic Common Schema (ecs), Logstash (logstash) и Graylog Extended Log Format (gelf). Для включения логирования в файл в структурном формате используется параметр logging.structured.format.file, а для вывода в консоль — logging.structured.format.console.

Docker Compose теперь может принимать аргументы командной строки через новые параметры spring.docker.compose.start.arguments и spring.docker.compose.stop.arguments, а также поддерживает переменную окружения POSTGRES_HOST_AUTH_METHOD=trust. Spring Boot добавил различные контейнерные образы для Docker Compose и Testcontainers: Redis Stack и Redis Stack Server с redis/redis-stack и redis/redis-stack-server, Grafana LGTM с grafana/otel-lgtm и класс LgtmStackContainer для Testcontainers. Для Kafka теперь доступна поддержка Testcontainers с использованием класса KafkaContainer.

Сборка OCI-образов с использованием билдера из недоверенных источников стала более безопасной благодаря функции trustBuilder (документацию можно найти для Maven и Gradle). Опция imagePlatform позволяет создавать образы для операционных систем и архитектур, отличающихся от платформы хоста. По умолчанию билдер Cloud Native Buildpacks для JVM-приложений — это paketobuildpacks/builder-jammy-java-tiny, что обеспечивает создание более компактных образов. Он поддерживает ARM и x64 прямо из коробки.

В Spring Boot появился новый режим доступа для актуаторов — «read‑only» — наряду с существующими режимами «unrestricted access» (ранее назывался enabled) и «none» (ранее назывался disabled). Параметр management.endpoints.enabled-by-default теперь называется management.endpoints.access.default, а management.endpoint.<id>.enabled — management.endpoint.<id>.access. Новый актуатор /actuator/info показывает информацию о SSL-сертификатах, включая те, чей срок действия скоро истечет. Актуатор /scheduledtasks предоставляет более детальную информацию о запланированных тасках, включая время следующего выполнения, статус последнего выполнения и исключения.

Embedded веб-серверы теперь по умолчанию корректно завершают свою работу. Для изменения этого поведения можно установить параметр server.shutdown в значение immediate. Веб-сервер Undertow поддерживает виртуальные потоки, если они включены. RestClient и RestTemplate теперь поддерживают пять HTTP-клиентов: Apache HTTP Components (HttpComponentsClientHttpRequestFactory), Jetty Client (JettyClientHttpRequestFactory), Reactor Netty HttpClient (ReactorClientHttpRequestFactory), JDK HttpClient (JdkClientHttpRequestFactory), и Simple JDK HttpURLConnection (SimpleClientHttpRequestFactory).

После возвращения поддержки embedded брокера в ActiveMQ Classic, Spring Boot снова может автоматически его конфигурировать с использованием зависимости org.apache.activemq:activemq-broker. Однако, в отличие от Spring Boot 2.7.x, стартер ActiveMQ теперь поддерживает только клиент. Свойство observability spring.application.group объединяет приложения, которые являются частью одной системы. Docker Compose и Testcontainers теперь поддерживают логирование OTLP.

Spring Boot больше не зависит от библиотеки OkHttp, поэтому пользователям, которым она необходима, придется самостоятельно управлять версией. Аннотации @MockBean и @SpyBean устарели и заменены на аннотации Spring Framework @MockitoBean и @MockitoSpyBean. Spring Boot 3.4 работает только с Gradle версии 7.6.4 и 8.4.0 или новее.

Обновления зависимостей в Spring Boot 3.4 включают Spring Security 6.4, Spring Session 3.4, Spring Integration 6.4, Spring Batch 5.2 и Spring for Apache Kafka 3.3. Среди сторонних обновлений: Log4j 2.24, Liquibase 4.29, Flyway 10.20, MySQL 9.1.0, MongoDB 5.2.0, Hibernate 6.6, Reactor 2024.0.0, Kafka 3.8, Jackson 2.18, Apache Http Client 5.4, Micrometer 1.14, HtmlUnit 4.3.0, Selenium 4.25.0, Mockito 5.13, JUnit Jupter 5.11 и Testcontainers 1.20.3.

Spring Framework 6.0 и 6.1, а также Spring Boot 3.0 и 3.2 предлагали больше пользовательских функций, таких как Ahead-of-Time-компиляция с использованием GraalVM Native Image или поддержка виртуальных потоков и CRaC. В Spring Framework 6.2 и Spring Boot 3.4 таких громких обновлений нет. Это неудивительно для последнего года поколения Spring Framework: в 2021 году не было никаких релизов Spring Framework перед выходом версии 6.0 в 2022 году.

Юрген Хёллер (Juergen Hoeller) недавно анонсировал выход нового поколения Spring Framework 7 и Spring Boot 4 в ноябре 2025 года. Эти версии сохранят поддержку JDK 17, но «примут грядущий JDK 25 LTS», выпуск которого ожидается за два месяца до этого. Базовая версия Kotlin будет обновлена до версии 2, а Jakarta EE — с 9 до 11, что включает Tomcat 11, Hibernate ORM 7 и Hibernate Validator 9. Spring Framework также перейдет на использование JSpecify для обеспечения null-safety подхода.

Юрген Хёллер и Себастьян Делюз (Sébastien Deleuze), основной коммитер Spring Framework из Broadcom, любезно ответили на вопросы InfoQ.

InfoQ: Spring Framework 6 — это самое короткое поколение с тех пор, как версия 2.0 завершилась через три года в 2009 году. Почему?

Юрген Хёллер: Исторически поколения нашего фреймворка формировались под влиянием конкретных факторов своего времени. Мы никогда не ставили целью фиксированную продолжительность жизненного цикла поколения, а скорее ориентировались на определённый набор функций, который служил триггером для нового релиза. По этой причине наш цикл минорных релизов обычно составлял раз в год, но иногда мы пропускали год. Долгосрочная поддержка всегда предоставлялась для последнего функционального релиза каждого поколения, и это оставалось неизменным на протяжении многих лет.

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

InfoQ: Spring Framework 6 требовал JDK 17, которому на тот момент был всего один год. Spring Framework 7 сохраняет JDK 17 в качестве базовой версии, несмотря на то, что JDK 21 будет уже двухлетней. Почему Spring 7 впервые с 2006 года остаётся на базовой версии Java предыдущего поколения?

Хёллер: Выбор базовой версии обычно диктуется техническими соображениями. JDK 17 предложил множество улучшений по сравнению с JDK 11 (альтернативой в то время), поэтому мы сразу выбрали его для Spring Framework 6.0. Это позволило значительно модернизировать наш код и дать некий толчок индустрии, хотя это усложнило процесс миграции, особенно в сочетании с переходом на неймспейс Jakarta EE.

Для Spring Framework 7.0 техническая выгода от обновления базовой версии практически отсутствует. Специфические возможности новых версий Java могут быть легко реализованы с помощью multi-release jars, как это уже сделано для виртуальных потоков в Java 21. Текущий консенсус в индустрии явно указывает на базу в виде Java 17, например, в API Jakarta EE 11 и грядущем поколении провайдеров. Поскольку наш текущий код фреймворка не получит преимуществ от обновления базовой версии, мы планируем оставить Java 17 в качестве базы, предоставляя при этом полноценную поддержку Java 21 и Java 25 в рамках одного поколения. Вместо этого повышение базы произойдёт за счёт перехода на API Jakarta EE 11, такие как Jakarta Servlet 6.1 и Jakarta Persistence 3.2, а также Kotlin 2.

Мы в целом рекомендуем использовать последнюю LTS-версию Java для production deployment, независимо от базовой версии, которая является лишь техническим минимумом, поддерживаемым фреймворком в runtime. Для Spring Framework 7.0, несмотря на базу в виде Java 17, наш основной фокус направлен на поддержку Java 25. В будущем мы рассматриваем Java 25 как привлекательную новую базу для более широкой Java-экосистемы. Однако пока лучшее, что мы можем сделать, — это поддерживать её в рамках диапазона версий JDK.

InfoQ: В анонсе Spring 7 упоминался JSpecify, который стандартизирует аннотации для null-safety. Как обеспечивается null-safety в Spring Framework 6 и Spring Boot 3 сейчас? И какие изменения нас ждут в Spring Framework 7 и Spring Boot 4?

Себастьян Делюз: В Spring Framework 6 предоставляются аннотации для null-safety, такие как @Nullable из пакета org.springframework.lang. Эти аннотации являются мета-аннотациями для JSR 305 (замороженного, но широко используемого JSR), что позволяет инструментам, таким как IDEA или Kotlin, обеспечивать поддержку null-safety в универсальном формате.

В Spring Framework 7 мы планируем перейти на аннотации JSpecify — отраслевой стандарт, над которым команда Spring работала несколько лет, — и объявить как deprecate аннотации для null-safety из Spring.

Переход на JSpecify принесёт следующие улучшения:

• Чёткие спецификации для инструментов и документации для конечных пользователей.

• Избежание split-package, вызванного аннотациями JSR 305, что улучшит совместимость с JPMS.

• Улучшенная интеграция с Kotlin.

• Возможность указывать null-safety для generic-типа, массивов и элементов varargs.

• Применимость для других библиотек, не основанных на Spring, например, Reactor и Micrometer.

Мы также планируем всесторонне специфицировать null-safety API в других проектах Spring.

InfoQ: В анонсе Spring 7 говорилось о «стратегическом выравнивании с GraalVM и Project Leyden». Почему это выравнивание стратегическое?

Делюз: Наше выравнивание с GraalVM и Project Leyden стратегическое по трём причинам.

Во-первых, они дополняют друг друга. GraalVM обеспечивает значительные преимущества, такие как мгновенный запуск/разогрев, но с издержками в виде длительного времени сборки и проблем совместимости. AOT-кэш Project Leyden ускоряет запуск в 3–4 раза — возможно, не так значительно, как native-образы GraalVM, но достаточно для многих пользователей и с минимальными побочными эффектами при использовании поддержки Spring Boot. Сосредоточение на этих двух технологиях значительно повысит эффективность Spring Boot 4 для различных сценариев развертывания.

Во-вторых, команда Spring активно сотрудничает с обеими командами в рамках R&D, о чём свидетельствуют совместные доклады с командой Java Platform по Project Leyden и с командой GraalVM на тему native-образов на Devoxx Belgium 2024.

В-третьих, это стратегическое выравнивание, поскольку мы сосредотачиваем усилия R&D на этих технологиях, предлагая два золотых пути для разработчиков Spring, которые ищут руководство. Обе технологии могут использовать оптимизации Spring Ahead-Of-Time и Buildpacks. Мы ожидаем, что AOT-кэш Project Leyden станет преемником Class Data Sharing (CDS), который мы уже поддерживаем в Spring Boot 3.3.

На данный момент мы не планируем значительных усилий по Project CRaC, который сложнее использовать для наших пользователей (см. сравнение). Таким образом, с AOT-кэшем Project Leyden на JVM (и CDS в промежуточный период) и native-образами на базе GraalVM мы создаём две основные опции для повышения эффективности в поколении Spring Boot 4.

Для получения дополнительной информации ознакомьтесь с примечаниями к релизу Spring Framework 6.2 и Spring Boot 3.4.

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

Ждем всех, присоединяйтесь!