Von Elyndra Valen & Code Sentinel, Java Fleet Systems Consulting
Schwierigkeit: 🟢 Einsteiger
Lesezeit: 15 Minuten
Voraussetzungen: Spring Boot 3.x Grundkenntnisse
Serie: Spring Boot 4 Migration (Teil 1 von 3)
⚡ Das Wichtigste in 30 Sekunden
Dein Problem: Spring Boot 4.0 wurde am 20. November 2025 released. Du fragst dich: Upgrade jetzt oder warten?
Die Lösung: Wir geben dir einen kompletten Überblick über alle Neuerungen, Breaking Changes, und eine ehrliche Einschätzung.
Heute lernst du:
- ✅ Die wichtigsten Neuerungen in Spring Boot 4
- ✅ Was die Modularisierung für dich bedeutet
- ✅ Wann du migrieren solltest – und wann besser nicht
Für wen ist dieser Artikel?
- 🌱 Einsteiger: Du bekommst den Überblick, was sich ändert
- 🌿 Erfahrene: Du erfährst, welche Breaking Changes dich betreffen
- 🌳 Profis: Im Bonus findest du die Migrationsstrategie-Matrix
Zeit-Investment: 15 Minuten (lohnt sich!)
👋 Elyndra & Code Sentinel: „Die vierte Generation ist gelandet!“
Hi! 👋
Elyndra hier, zusammen mit Code Sentinel. Als wir gehört haben, dass Spring Boot 4 released wurde, war unsere erste Reaktion… unterschiedlich.
Elyndra: „Endlich! Die Modularisierung wird so viel aufräumen!“
Code Sentinel: „Hmm. Zwei Wochen alt. Lass uns erstmal die Release Notes lesen.“
Das fasst eigentlich die zwei Perspektiven zusammen, die du bei jeder Major-Version-Entscheidung brauchst: Die Begeisterung für neue Features UND den pragmatischen Realitäts-Check.
In diesem Artikel kombinieren wir beides. Du bekommst sowohl das „Was ist neu und cool“ als auch das „Was kann schiefgehen und wie gehst du damit um“.
Lass uns eintauchen! 🚀
🟢 GRUNDLAGEN
Was ist Spring Boot 4?
Spring Boot 4.0 ist die neueste Major-Version des beliebtesten Java-Frameworks. Released am 20. November 2025, baut es auf Spring Framework 7.0 auf.
💡 Neu hier? Was ist ein Major Release?
Versionsnummern folgen meist dem Schema MAJOR.MINOR.PATCH (z.B. 4.0.0). Ein Major Release (3.x → 4.0) bedeutet: Größere Änderungen, möglicherweise Breaking Changes. Ein Minor Release (4.0 → 4.1) bringt neue Features ohne Breaking Changes.
Major Releases erfordern mehr Aufmerksamkeit bei der Migration.
Die fünf großen Neuerungen
1. Komplette Modularisierung 📦
Das ist die größte Änderung. Spring Boot war bisher ein relativ monolithisches Paket – spring-boot-autoconfigure enthielt ALLES. Jetzt ist es aufgeteilt in viele kleine, fokussierte Module.
Was bedeutet das für dich?
- Du lädst nur noch, was du wirklich brauchst
- Kleinerer Runtime-Footprint
- Klarere Abhängigkeiten in deiner
pom.xml
Elyndra’s Metapher: „Stell dir vor, du ziehst um und statt einem riesigen Container voller Sachen bekommst du genau die Kartons, die du brauchst. Küche, Bad, Schlafzimmer – einzeln beschriftet.“
2. JSpecify für Null-Safety 🛡️
Spring Boot 4 nutzt JSpecify-Annotations für portfolio-weite Null-Sicherheit.
// Diese Annotations helfen IDEs und Compilern @Nullable String getName(); // Kann null sein @NonNull User getUser(); // Nie null
Was bedeutet das für dich?
- Bessere IDE-Unterstützung (Warnungen bei potenziellen NullPointerExceptions)
- Sauberere APIs
- Besonders gut für Kotlin-Integration
3. API Versioning 🔢
Endlich eingebaut! Du kannst jetzt API-Versionen direkt in Spring annotieren:
@RestController
@RequestMapping("/api/users")
public class UserController {
@GetMapping(version = "1.0")
public User getUserV1() {
// Original-Implementation
}
@GetMapping(version = "2.0")
public UserDTO getUserV2() {
// Neue Implementation mit DTO
}
}
Was bedeutet das für dich?
- Keine Third-Party-Libs mehr nötig
- Saubere Versionierung deiner REST-APIs
- Einfachere Backward Compatibility
4. HTTP Service Clients 🌐
Du kannst jetzt REST-Clients deklarativ über Interfaces definieren – Spring generiert die Implementation:
@HttpExchange(url = "https://api.example.com")
public interface UserClient {
@GetExchange("/users/{id}")
User getUser(@PathVariable Long id);
@PostExchange("/users")
User createUser(@RequestBody User user);
}
Was bedeutet das für dich?
- Weniger Boilerplate-Code
- Ähnlich wie Feign, aber nativ in Spring
- Besser testbar
5. Java 25 Support ☕
Spring Boot 4 unterstützt Java 17 bis 25. Das Highlight: Virtual Threads sind jetzt Standard für den Web-Thread-Pool.
Was bedeutet das für dich?
- Bessere Performance bei I/O-lastigen Anwendungen
- Du kannst bei Java 17 bleiben (Minimum)
- Java 21+ empfohlen für Virtual Threads
Die wichtigsten Dependency-Upgrades
| Dependency | Spring Boot 3.5 | Spring Boot 4.0 |
|---|---|---|
| Spring Framework | 6.2.x | 7.0 |
| Spring Security | 6.4.x | 7.0 |
| Hibernate | 6.6.x | 7.1 |
| Micrometer | 1.14.x | 1.16 |
| HikariCP | 5.x | 7.0 |
| Gradle | 8.x | 8.14+ / 9.x |
Code Sentinel’s Anmerkung: „Hibernate 7.1 und Spring Security 7.0 sind die beiden, die dir am meisten Arbeit machen werden. Dazu mehr in Teil 2 und 3.“
🟡 PROFESSIONALS
Breaking Changes – Das musst du wissen
1. Package-Struktur hat sich geändert
Durch die Modularisierung beginnen Packages jetzt mit org.springframework.boot.<modul>:
// VORHER (Spring Boot 3.x) import org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration; // NACHHER (Spring Boot 4.x) import org.springframework.boot.webmvc.autoconfigure.WebMvcAutoConfiguration;
Betroffen: Alle, die Auto-Configuration-Klassen direkt importieren.
2. @ConfigurationProperties: Keine public fields mehr
// VORHER – funktioniert nicht mehr!
@ConfigurationProperties("app")
public class AppConfig {
public String name; // ❌
public int timeout; // ❌
}
// NACHHER – so muss es sein
@ConfigurationProperties("app")
public class AppConfig {
private String name; // ✅
private int timeout; // ✅
// Getter und Setter PFLICHT!
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public int getTimeout() { return timeout; }
public void setTimeout(int timeout) { this.timeout = timeout; }
}
Betroffen: Alle, die public fields in Config-Klassen nutzen.
3. MockitoTestExecutionListener entfernt
// VORHER – funktioniert nicht mehr!
@TestExecutionListeners(MockitoTestExecutionListener.class)
public class MyTest { }
// NACHHER
@ExtendWith(MockitoExtension.class)
public class MyTest { }
Betroffen: Alle mit älteren Test-Setups.
4. Spring Batch: In-Memory ist jetzt Default
Spring Batch speichert Metadaten nicht mehr automatisch in der Datenbank:
<!-- Wenn du DB-Metadaten brauchst: -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-batch-jdbc</artifactId>
</dependency>
Betroffen: Alle Batch-Anwendungen, die Job-History brauchen.
Classic Starters – Dein Rettungsanker
Die Modularisierung kann überwältigend sein. Deshalb bietet Spring Boot 4 Classic Starters an:
<!-- Statt vieler einzelner Module -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web-classic</artifactId>
</dependency>
Was macht das?
- Verhält sich wie Spring Boot 3.x
- Alle Auto-Configurations in einem Paket
- Gibt dir Zeit für die schrittweise Migration
Elyndra’s Empfehlung: „Nutze Classic Starters als Übergangslösung. Sie sind wie Stützräder – helfen am Anfang, aber irgendwann solltest du sie abnehmen.“
🔵 BONUS
Soll ich jetzt migrieren? Die Entscheidungsmatrix
Code Sentinel hat eine Entscheidungsmatrix erstellt:
| Deine Situation | Empfehlung | Begründung |
|---|---|---|
| Greenfield-Projekt | ✅ Ja, direkt mit 4.0 | Keine Migration nötig, alle Features nutzen |
| Spring Boot 3.5, gute Tests | ⏳ Q1 2026 | Warte auf 4.0.2/4.0.3 für Bugfixes |
| Spring Boot 3.5, wenig Tests | ⏳ Q2 2026 | Erst Testabdeckung erhöhen |
| Spring Boot 3.3 oder älter | ⚠️ Erst auf 3.5! | Stufenweise Migration |
| Spring Boot 2.x | ⚠️ Langer Weg | Jakarta-Migration zuerst (javax → jakarta) |
| Production-kritisch | ⏳ Q2 2026 | Warte auf Community-Feedback |
Support-Zeiträume – Du hast Zeit!
- Spring Boot 3.4: OSS-Support bis 31.Dezember 2025
- Spring Boot 3.5: OSS-Support bis 30.Juni 2026
- Spring Boot 4.0: Langzeit-Support OSS-Support bis 31.Dezember 2026
Code Sentinel: „Spring Boot 3.5 wird noch sieben Monate supported. Kein Grund zur Panik. Plane die Migration in Ruhe.“
Hinweis zur Support-Struktur: Der kostenlose Open-Source-Support (OSS) für Spring Boot Minor-Versionen läuft typischerweise 12-18 Monate. Danach gibt es Security-Patches und Updates nur noch über den kostenpflichtigen VMware Tanzu Spring Commercial Support. Das ist kein neues Konzept – aber seit der Broadcom-Übernahme beobachtet die Community aufmerksam, wie sich die Konditionen entwickeln. Für die meisten Teams bedeutet das: Regelmäßig upgraden bleibt die beste Strategie.
- spring.io/support
- spring.io/blog/2024/12/10/spring-support-updates/
- herodevs.com
- https://endoflife.date/spring-boot
- https://github.com/spring-projects/spring-boot/wiki/Supported-Versions – Offizielles GitHubWiki
- https://spring.io/support-policy/ – Offizielle VMware/Broadcom Support Policy
- https://spring.io/blog/2024/09/27/spring-boot-2-7-support-period-extended/ – Blog-Ankündigung zur 2.7 Verlängerung
Empfohlene Timeline
Dezember 2025: Lesen, verstehen, Sandbox-Projekt aufsetzen Januar 2026: Sandbox-Tests, Team-Schulung Februar 2026: Non-kritische Services migrieren März 2026: Lessons Learned dokumentieren April 2026: Production-Migration planen Mai 2026: Production-Migration (mit Rollback-Plan!)
💬 Real Talk: Das Team diskutiert Spring Boot 4
Java Fleet Büro, Montag 9:15 Uhr. Das Weekly beginnt, Franz-Martin hat Kaffee für alle.
Nova: (aufgeregt) „Habt ihr gesehen? Spring Boot 4 ist raus! Die HTTP Service Clients sind SO clean!“
Code Sentinel: (nippt am Kaffee) „Wann genau?“
Nova: „Vor zwei Wochen. 20. November.“
Code Sentinel: „Zwei Wochen. Also quasi noch feucht hinter den Ohren.“
Elyndra: (schmunzelt) „Er meint: frisch released. Aber Nova hat recht – die Features sehen gut aus. Ich hab mir gestern die Modularisierung angeschaut. Das räumt einiges auf.“
Franz-Martin: „Was ist eure Einschätzung? Migrieren wir?“
Code Sentinel: „Nicht sofort. Nicht für Production. Aber…“ (Pause) „…ich bin nicht mehr so paranoid wie früher. Sandbox-Projekt? Klar, warum nicht.“
Nova: (überrascht) „Wow, das ist neu. Der alte Code Sentinel hätte gesagt: ‚Warten bis 4.3!'“
Code Sentinel: (grinst) „Menschen ändern sich, Nova. Manchmal ist ‚gut genug mit Rollback-Plan‘ besser als ‚perfekt aber nie fertig‘.“
Elyndra: „Ich würde vorschlagen: Nova, du setzt ein Sandbox-Projekt auf. Ich dokumentiere mit dir die Stolperfallen. Code Sentinel reviewt die Security-Aspekte. In einem Monat wissen wir mehr.“
Franz-Martin: „Klingt nach einem Plan. Wer schreibt den Blogpost?“
Code Sentinel: „Elyndra und ich. Zusammen.“
Elyndra: (nickt) „Sie bekommt die Erklärungen, er den Realitäts-Check. Passt.“
Nova: „Und ich?“
Elyndra: „Du testest alles, was wir schreiben. Wenn du es verstehst, verstehen es alle.“
Nova: „Deal! 😊“
❓ Häufig gestellte Fragen
Frage 1: Kann ich direkt von Spring Boot 2.x auf 4.0 upgraden?
Technisch ja, praktisch nein. Der offizielle Weg ist: 2.x → 3.5 → 4.0.
Warum? Die Jakarta-Migration (javax.* → jakarta.*) muss zuerst passieren. Das ist ein eigenes Projekt mit eigenen Herausforderungen. Wenn du das überspringst, hast du ZWEI Major-Migrationen gleichzeitig – das ist ein Rezept für Chaos.
Frage 2: Muss ich alle meine Imports ändern wegen der Modularisierung?
Nicht unbedingt. Die Classic Starters funktionieren wie gewohnt. Aber langfristig solltest du auf die modularen Starters umsteigen:
- Kleinerer Footprint
- Klarere Dependencies
- Bessere Startup-Zeit
Elyndra: „Denk daran wie Aufräumen. Kurzfristig mehr Arbeit, langfristig weniger Chaos.“
Frage 3: Was ist mit Spring Cloud?
Spring Cloud 2025.1.0 ist kompatibel mit Spring Boot 4. Aber check die Kompatibilitätsmatrix für deine spezifischen Starter – nicht alle Libraries sind sofort bereit.
Frage 4: Funktioniert mein Projekt noch mit Java 17?
Ja. Java 17 ist das Minimum für Spring Boot 4. Java 21 oder 25 werden empfohlen für Virtual Threads und bessere Performance, aber 17 funktioniert.
Frage 5: Wie lange wird Spring Boot 3.5 noch supported?
OSS-Support bis Juni 2026. Commercial Support länger. Du hast also mindestens sechs Monate Zeit für eine entspannte Migration.
Frage 6: Was ist das Erste, was ich tun sollte?
- Diesen Artikel bookmarken 😉
- Ein Sandbox-Projekt mit Spring Boot 4 aufsetzen (start.spring.io)
- Deine bestehende App verstehen: Welche Starters nutzt du? Welche Custom-Configurations?
- Teil 2 dieser Serie lesen, wenn er erscheint
Frage 7: Bernd meinte letztens, Major Releases sind „kontrolliertes Chaos“. Hat er recht?
(Elyndra schmunzelt)
Lowkey ja. Die ersten Wochen nach einem Major Release sind immer… interessant. Bugs werden gefunden, Edge Cases tauchen auf, die Dokumentation wird nachgebessert.
Aber „kontrolliertes Chaos“ ist der Schlüssel: kontrolliert. Mit Tests, Rollback-Plan und Staging-Environment ist das Risiko überschaubar.
Real talk: Wer ohne Tests migriert, migriert zweimal. Und das sagt nicht nur Bernd – das sagt die bittere Erfahrung. 😅
Code Sentinel: „Bernd hat übrigens auch mal gesagt: ‚Der beste Zeitpunkt zu migrieren ist, wenn du bereit bist. Nicht wenn das Release erscheint.‘ Da hat er recht.“
📦 Downloads
🎯 spring-boot-4-demo.zip
- Minimales Spring Boot 4.0 Projekt
- Zeigt neue Features (HTTP Service Client, API Versioning)
- Maven + Gradle Varianten
- README mit Quick Start
📁 spring-boot-4-demo/ ├── 📁 maven-version/ │ ├── pom.xml │ └── src/... ├── 📁 gradle-version/ │ ├── build.gradle │ └── src/... └── README.md
📋 migration-checklist.pdf
- Alle Breaking Changes auf einen Blick
- Checkbox-Liste für systematische Migration
- Zum Ausdrucken und Abhaken
🔗 Externe Links
Offizielle Dokumentation:
Tools:
- Spring Initializr – Jetzt mit Boot 4 Support
- OpenRewrite – Automatisierte Migration
Für Einsteiger:
🖼️ Grafiken in diesem Artikel
- 01_spring_boot_4_features.svg – Übersicht der Neuerungen
- 02_migration_entscheidungsbaum.svg – Entscheidungshilfe
- 05_support_timeline.svg – Support-Zeiträume
🎯 Wie geht’s weiter?
Teil 2: Migration Step-by-Step
Wir nehmen ein echtes Spring Boot 3.5 Projekt und migrieren es live auf 4.0. Jeder Compile-Fehler, jede Lösung, alles dokumentiert.
Erscheint: Donnerstag
Elyndra Valen ist Senior Software Architect bei Java Fleet Systems Consulting. Sie liebt Legacy-Code-Archäologie und erklärt komplexe Themen so, dass sie jeder versteht.
Code Sentinel ist Technical Project Manager und Security-Experte bei Java Fleet. Er sorgt dafür, dass Migrationen nicht in Katastrophen enden – pragmatisch, nicht paranoid.
Fragen? Feedback?
elyndra.valen@java-developer.online | code.sentinel@java-developer.online
Teil 1 von 3 der Spring Boot 4 Migration Serie
java-developer.online • Dezember 2025
