Spring Boot 3 vs 4 — co sprawdzić przed migracją aplikacji

Zmiana wersji w pom.xml trwa chwilę. Ustalenie, czy aplikacja nadal uruchamia się poprawnie, zachowuje kontrakt API i współpracuje z zależnościami, zajmuje znacznie więcej czasu. W migracji głównej wersji właśnie to jest najważniejsza praca.

Ten wpis dotyczy przejścia z linii Spring Boot 3.5 do 4.0. Nie opisuje wszystkich wydań 3.x i 4.x jako jednorodnych zestawów funkcji. Szczegóły zależą od konkretnej wersji, więc przed migracją trzeba sprawdzić jej dokumentację i release notes.

Najpierw uporządkuj punkt wyjścia

Jeżeli aplikacja działa na starszej linii 3.x, warto najpierw przejść do 3.5 i usunąć użycie wycofywanych API. Pozwala to oddzielić problemy poprzednich aktualizacji od zmiany na 4.0. Taki kierunek opisuje oficjalny przewodnik migracji.

Przed zmianą zapisz stan odniesienia: wynik testów, przykładowe odpowiedzi JSON, konfigurację środowiska i pomiary ważnych endpointów. Sprawdź również biblioteki integracyjne oraz własne startery. To one mogą ograniczyć termin migracji, nawet jeśli kod biznesowy wymaga niewielu zmian.

Java 17 nadal jest minimum

Spring Boot 4.0 wymaga co najmniej Java 17, Spring Framework 7 i kontenera zgodnego z Servlet 6.1 dla aplikacji servletowej. Nowa wersja Boota nie oznacza automatycznie obowiązku przejścia na Java 25. Wymagania i zakres zgodności opisuje dokumentacja platformy 4.0.

Aktualizacja JDK może być korzystna, ale to osobna decyzja. Warto rozdzielić ją od aktualizacji frameworka, jeśli pomoże to diagnozować regresje. Przy wdrożeniu WAR-a trzeba sprawdzić kontener docelowy, a nie tylko to, że aplikacja działa z serwerem wbudowanym.

Obszar	Spring Boot 3.5	Spring Boot 4.0
Spring Framework	Linia 6.2	Linia 7.0
Minimalna Java	17	17
Domyślna linia Jacksona	2	3
Starter MVC	spring-boot-starter-web	Preferowany spring-boot-starter-webmvc
Auto-konfiguracja	Mniej rozdrobniona struktura	Moduły przypisane technologiom

To skrót obszarów do sprawdzenia, nie kompletna macierz wszystkich zarządzanych zależności.

Startery stały się bardziej precyzyjne

Boot 4 dzieli wsparcie technologii na mniejsze moduły i odpowiadające im startery. Ma to konsekwencje dla kodu korzystającego bezpośrednio z klas auto-konfiguracji oraz dla technologii, które wcześniej aktywowały się dzięki samej obecności biblioteki.

Dla przykładowej aplikacji MVC z Flywayem fragment zależności po migracji może wyglądać tak:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-webmvc</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-flyway</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-webmvc-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

To fragment POM-a zakładający zarządzanie wersjami przez parent lub BOM Boot 4.0. Nie zawiera konfiguracji konkretnej bazy ani wszystkich zależności projektu. Dla wybranej bazy Flyway może potrzebować dodatkowego modułu.

Stary starter web jest w 4.0 wycofywany, a nie po prostu nieistniejący. Nowe nazwy i testowe startery warto jednak przyjąć świadomie. Uzasadnienie zmian oraz przykłady opisuje artykuł zespołu Spring Boot o modularizacji.

Jackson 3: kompilacja to dopiero początek

Przejście na Jackson 3 obejmuje zmianę przestrzeni nazw wielu klas na tools.jackson. Adnotacje takie jak @JsonProperty pozostają w com.fasterxml.jackson.annotation, więc globalna zamiana wszystkich importów byłaby błędem.

Trzeba przyjrzeć się własnym serializerom, modułom i konfiguracji mappera. Mechanizmy przejściowej zgodności z Jacksonem 2 nie powinny zastępować planu migracji. Kierunek wsparcia opisuje wprowadzenie Jackson 3 w Spring.

Praktyczny sprawdzian to zestaw przykładów wejść i wyjść API. Czy kwota zachowuje ustalony format? Czy daty mają ten sam zapis? Jak obsługiwane są brakujące pola i null? Czy odpowiedź błędu nadal odpowiada kontraktowi klienta?

Nie zakładamy, że każda z tych rzeczy na pewno się zmieni. Traktujemy je jako obszary, w których nieoczekiwana różnica byłaby kosztowna.

Testy i wdrożenie sprawdzaj osobno

Po dostosowaniu zależności sprawdź importy adnotacji testowych, testy wycinków oraz pełny start aplikacji. Kompilacja testu nie potwierdza jeszcze, że ładowany kontekst zawiera właściwe komponenty.

Proponowana kolejność weryfikacji:

1. Zbudować projekt i uruchomić testy na uporządkowanej wersji 3.5.
2. Zmienić wersję Boota, zależności i niezbędne importy.
3. Zweryfikować JSON, bezpieczeństwo oraz integracje z bazą i usługami zewnętrznymi.
4. Uruchomić docelowy artefakt w środowisku podobnym do produkcyjnego.
5. Porównać opóźnienia, błędy, zużycie zasobów i działanie monitoringu.

Migracja nie jest dobrym momentem na przypadkową przebudowę domeny. Im bardziej skupiony zakres, tym łatwiej wyjaśnić różnicę w zachowaniu i wycofać zmianę.

Boot 4 nie daje automatycznej gwarancji szybszego API. Decyzję warto oprzeć na zgodności zależności, potrzebnych funkcjach i planie utrzymania platformy. Udana migracja oznacza przede wszystkim, że aplikacja działa poprawnie na nowej podstawie, a zespół wie, co sprawdził.