Spring Boot 4: kompletny przewodnik od nowości po pełną migrację

Autor artykułu: Abdelaziz LOUARIT,
programista Java w MARGO.

Wprowadzenie

Spring Boot 4 to ważny kamień milowy dla nowoczesnego ekosystemu Java.
Po kilku latach stabilizacji wokół Spring Boot 3 nowa wersja realizuje trzy główne cele: uproszczenie pracy programistów, utrwalenie dobrych praktyk cloud-native oraz dalsze skrócenie czasu uruchamiania i poprawę obserwowalności.

Oparty na Spring Framework 7.x, rozwija osiągnięcia poprzednich wersji, a jednocześnie wprowadza natywne funkcje poświęcone odporności, obserwowalności i wydajności.

Dostosowany do Javy 17 (LTS), która staje się nowym minimalnym wymaganiem, oraz do Jakarta EE 11, Spring Boot 4 jest wyraźnie ukierunkowany na aplikacje cloud-native i serverless. Wyróżnia się wyraźnym ograniczeniem zależności zewnętrznych, wbudowanym null-safety dzięki JSpecify oraz zoptymalizowaną obsługą kompilacji AOT (Ahead-of-Time) i obrazów natywnych GraalVM.

Ta wersja stawia na prostotę i spójność: mniej niejawnej konfiguracji, bardziej przewidywalne zachowanie i lepsze przygotowanie do środowisk kontenerowych, w których liczy się szybki start.

W porównaniu ze Spring Boot 3 (Java 17 / Jakarta EE 10) oficjalne benchmarki wskazują na skrócenie czasu uruchamiania w trybie natywnym nawet o 50% oraz zmniejszenie zużycia pamięci o 30–40%.

Funkcje gotowe do produkcji

Wbudowana odporność: @Retryable i @ConcurrencyLimit

Odporność, wcześniej obsługiwana przez Spring Retry (lub Resilience4j), jest teraz natywną funkcją Spring Boot 4. Te adnotacje wykorzystują Project Reactor do strategii backoff i integrują Micrometer na potrzeby monitoringu.

import org.springframework.retry.annotation.Retryable;
import org.springframework.retry.annotation.Backoff;
import org.springframework.stereotype.Service;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
import org.springframework.service.annotation.ConcurrencyLimit; // New in Spring Boot 4

@Service
public class PaymentService {

    @Retryable(
        maxAttempts = 4, // Includes the initial attempt
        backoff = @Backoff(delay = 1000, multiplier = 2.0) // Exponential backoff with jitter
    )
    @ConcurrencyLimit(value = 5) 
    public void processPayment(String paymentId) {
        // Logic: External call (e.g., RestTemplate or WebClient)
        externalApi.call(paymentId);
    }
}

Natywne wersjonowanie API

Wersjonowanie jest teraz jawnie określane w mapowaniach, więc nie trzeba duplikować kontrolerów ani tworzyć zbędnych ścieżek. To ogranicza dług techniczny i porządkuje ewolucję kontraktów API.

import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.GetMapping;
import java.util.List;

@RestController
@RequestMapping("/api")
public class UserController {

    @GetMapping(path = "/users", version = "1", produces = "application/vnd.app.v1+json")
    public List getUsersV1() { return List.of(new UserV1("Alice", "ADMIN")); }

    @GetMapping(path = "/users", version = "2", produces = "application/vnd.app.v2+json")
    public List getUsersV2() { return List.of(new UserV2("Alice", "ADMIN", 30)); } // Added 'age' field
}

Wystarczy ustawić spring.mvc.versioning.strategy=header w pliku application.yml.

spring:
  mvc:
    versioning:
      strategy: header

Null‑safety (JSpecify)

Adnotacje nullowalności czynią kontrakty jawnymi: parametry obowiązkowe, wartości opcjonalne i typy zwracane, które mogą przyjmować null. IDE wykorzystują je, aby zapobiegać wyjątkom NPE (NullPointerException) i podpowiadać przy autouzupełnianiu.

import org.jspecify.annotations.NonNull;
import org.jspecify.annotations.Nullable;

public final class EmailService {

    public void send(@NonNull String to, @Nullable String cc, @NonNull String body) {
        java.util.Objects.requireNonNull(to); // Compile-time check via plugins
        // ...
    }
}

Wydajność: AOT i buildy natywne (GraalVM)

Szybszy start i mniejsze zużycie pamięci stały się celami pierwszorzędnymi. Spring Boot 4 wzmacnia integrację z AOT i upraszcza korzystanie z GraalVM. AOT (Ahead-of-Time) kompiluje beany na etapie budowania, skracając czas uruchamiania nawet o 90% w trybie natywnym. Rozszerzona konfiguracja Maven:

<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
    <version>0.10.3</version> <!-- Version aligned with Boot 4 -->
    <executions>
        <execution>
            <goals><goal>compile</goal><goal>build</goal></goals>
            <phase>package</phase>
        </execution>
    </executions>
    <configuration>
        <imageName>myapp</imageName>
        <buildArgs>--no-fallback --initialize-at-build-time</buildArgs>
    </configuration>
</plugin>

Rozbudowany Actuator (readiness/liveness, SSL, Mongo)

Endpointy health są bardziej ustandaryzowane: sondy readiness/liveness są domyślnie włączone, a nowe wskaźniki ułatwiają monitoring i integrację z Kubernetes.

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,env  
    endpoint:
    health:
      probes:
        enabled: true      
      show-details: always 
    ssl:
      enabled: true

Jackson 3 i Jakarta EE 11

Przejście na Jackson 3 i pełna migracja do `jakarta.*` modernizują ekosystem. Efekt uboczny: niektóre biblioteki zewnętrzne wymagają aktualizacji. Uwzględnij to na wczesnym etapie migracji.

import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.Email;

public record CreateUserRequest(@NotBlank String name, @Email String email) {}

Migracja do Spring Boot 4

Szybkie porównanie: Spring Boot 3 → 4

Migracja do Spring Boot 4 krok po kroku

Na podstawie oficjalnego przewodnika: Migration Guide – Spring Boot 4.0

Faza 1 — przygotowanie

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>4.0.0-RC2</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>