Планируешь миграцию на Spring Boot 4.0? Вместе с Eddy Benchek в новом переводе от команды Java Insider разбираем пять неочевидных проблем, с которыми столкнулась реальная production-команда при миграции, и показываем, как их исправить, чтобы вы не потеряли дни на поиски непонятных багов.

В теории всё просто: обновил зависимости, поправил ворнинги и запустил.

А что на практике? Всё ломается тихо. Ломается снова и снова. И часто там, где не ждёшь.

Недавно мы мигрировали наше приложение со Spring Boot 3.x на 4.0, и я хочу поделиться тем, что именно сломалось, почему это произошло и как мы это исправили, чтобы вы не потеряли дни на поиски багов.

Почему миграция на Spring Boot 4.0 сложнее, чем кажется

Spring Boot 4.0 — это не просто обновление версии. Это совокупность изменений из:

  • Обязательного перехода на Jakarta EE namespace

  • Spring Framework 7

  • Изменений в базовой версии Java

  • Рефакторинга Security и observability

Самое плохое, что проблемы часто не проявляются на этапе компиляции. Они возникают:

  • При старте приложения

  • В тестах (если повезет)

  • Уже в проде

1️⃣ Граничные случаи Jakarta EE, которые вы считали исправленными

Симптом
Приложение компилируется, но падает при запуске с ClassNotFoundException или NoSuchMethodError.

Даже если вы уже перешли на Jakarta в Spring Boot 3.x, некоторые транзитивные зависимости всё ещё тянут классы из javax.*.

Частые виновники:

  • старые библиотеки валидации

  • SOAP / JAXB инструменты

  • устаревшие servlet фильтры

Решение

Выполните:

mvn dependency:tree | grep javax

А потом:

  • принудительно укажите Jakarta-совместимые версии;

  • явно исключите старые транзитивные зависимости.

⚠️ То, что работало в 3.x, может вдруг сломаться в 4.0.

2️⃣ Spring Security конфигурация перестала компилироваться (или ещё хуже: незаметно изменила поведение)

Симптом
Security конфигурация компилируется, но аутентификация работает иначе.

Spring Security теперь требует явно прописывать всю конфигурацию.

Что сломалось:

  • удалены deprecated DSL;

  • изменены значения по умолчанию (особенно CSRF и управление сессиями);

  • кастомные фильтры больше не регистрируются автоматически.

Решение

Переходите на явные бины SecurityFilterChain и прекращайте полагаться на дефолтные значения.

@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .csrf(csrf -> csrf.disable())
        .authorizeHttpRequests(auth -> auth.anyRequest().authenticated());
    return http.build();
}

⚠️ Неявные security конфигурации исчезли и теперь всё нужно указывать явно.

3️⃣ Привычные стартеры внезапно пропали

Симптом
Приложение не запускается из-за отсутствующих бинов.

Некоторые Spring Boot стартеры были:

  • переименованы

  • разделены

  • или полностью удалены

Особенно это касается:

  • observability

  • расширений actuator

  • устаревших интеграций

Решение

Проверьте ваши стартеры вручную. Не доверяйте старому списку.

mvn dependency:tree | grep spring-boot-starter

Замените удалённые стартеры на:

  • явные библиотеки

  • или новые модульные альтернативы

4️⃣ Тесты отвалились из-за незаметного изменения версии Java

Симптом
Тесты падают локально, но проходят в CI (или наоборот).

Spring Boot 4.0 активнее толкает к современной Java (Java 21+).

Что сломалось:

  • образы Testcontainers

  • совместимость ByteBuddy / Mockito

  • JVM флаги удалены или игнорируются

Решение

  • Выровняйте локальную версию Java, версию Java в CI и Maven toolchains

  • Агрессивно обновляйте библиотеки для тестирования

💬 Комментарий Java Insider

Автор пишет, что Spring Boot 4.0 повысил минимальные требования к Java, но это изменение может пройти незаметно. В результате у вас локально, в CI и в Docker-образах Testcontainers могут быть разные версии.

Из-за этого тесты ведут себя по-разному в разных окружениях, и вы тратите часы на поиски бага в Spring, хотя проблема просто в рассинхронизации версий JVM.

5️⃣ Actuator и метрики изменили поведение без ошибок

Симптом
Всё работает, но метрики исчезли.

Spring Boot 4 рефакторит дефолты observability:

  • endpoints отключены по умолчанию

  • переименованы метрики

  • изменены правила экспозиции

Решение

Явно объявите экспозицию actuator:

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics

Когда мы поняли, что для миграции нужен чеклист

После исправления третьей критической проблемы мы остановились и осознали:

Это не одна миграция — это паттерн.

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

👉 Полный гайд по миграции Spring Boot 3.x → 4.0

Он включает:

  • шаги аудита зависимостей

  • паттерны миграции security

  • исправления для тестов и CI

  • изменения в actuator и observability

Что было самым странным, что сломалось во время вашей миграции? Давайте обменяемся опытом 👇

Больше материалов о Spring Boot, Java и backend-разработке ищите в нашем телеграм-канале Java Insider.