Die Begriffe “Spring” und “Spring Boot” werden oft synonym verwendet. Das ist verständlich – beide stammen aus demselben Haus, lösen ähnliche Probleme und werden meist zusammen eingesetzt. Trotzdem handelt es sich um zwei unterschiedliche Projekte mit unterschiedlichen Zielen.
Spring Framework erschien 2003 als Antwort auf die Komplexität von Java EE. Die Enterprise-Edition von Java war damals ein Moloch aus XML-Konfiguration, Application Servern und abstrakten Schnittstellen. Spring versprach Vereinfachung – und lieferte.
Aber “einfacher als Java EE” bedeutete nicht “einfach”. Eine Spring-Anwendung der frühen Jahre bestand aus Dutzenden XML-Dateien. Die Konfiguration war explizit, präzise und furchtbar aufwändig. Ein simpler Webservice erforderte hunderte Zeilen Boilerplate.
Spring Boot erschien 2014 mit einem radikalen Versprechen: Produktionsreife Spring-Anwendungen mit minimalem Aufwand. Keine XML-Dateien mehr. Keine manuelle Server-Konfiguration. Kein Dependency-Management-Chaos.
Spring Framework ist das Fundament. Es stellt die Kernkonzepte bereit, auf denen alles andere aufbaut.
Der IoC Container verwaltet die Lebenszyklen aller Komponenten. Er instanziiert Objekte, injiziert Abhängigkeiten und räumt am Ende wieder auf.
Die Aspektorientierte Programmierung ermöglicht Querschnittsfunktionen wie Logging, Transaktionen oder Security, ohne dass du jeden Methodenaufruf manuell instrumentieren musst.
Der Application Context ist die zentrale Registry für alle Beans. Er weiß, welche Komponenten existieren und wie sie zusammenhängen.
Die Erweiterungsmodule bauen auf diesem Fundament auf. Spring MVC für Webanwendungen, Spring Data für Datenbankzugriff, Spring Security für Authentifizierung. Jedes Modul ist optional – du verwendest nur, was du brauchst.
Spring Boot ist keine Alternative zu Spring Framework. Es ist eine Schicht darüber. Eine Schicht, die Arbeit abnimmt.
Die Auto-Konfiguration erkennt, welche Bibliotheken im Classpath liegen, und konfiguriert sie automatisch. Liegt der MongoDB-Treiber im Classpath? Spring Boot konfiguriert eine Verbindung. Liegt Thymeleaf vor? Spring Boot registriert die Template-Engine. Du musst nichts tun – es funktioniert einfach.
Die Starter-Abhängigkeiten bündeln zusammengehörige
Bibliotheken. Statt zehn einzelne Dependencies für Web-Entwicklung zu
definieren, fügst du spring-boot-starter-web hinzu. Der
Starter zieht alles Nötige nach.
Der Embedded Server eliminiert externe Application
Server. Tomcat, Jetty oder Netty laufen direkt in deiner Anwendung. Ein
java -jar myapp.jar startet alles. Keine Installation,
keine Konfiguration.
Der Actuator liefert produktionsreife Monitoring-Endpoints: Health-Checks, Metriken, Environment-Informationen. Alles out-of-the-box.
Der Unterschied lässt sich so zusammenfassen: Spring Framework definiert was möglich ist. Spring Boot definiert wie es standardmäßig funktioniert.
Du kannst Spring Framework ohne Spring Boot verwenden – aber du wirst viel Zeit mit Konfiguration verbringen. Du kannst Spring Boot nicht ohne Spring Framework verwenden – es baut darauf auf.
| Aspekt | Spring Framework | Spring Boot |
|---|---|---|
| Fokus | Architektur und Konzepte | Produktivität und Konventionen |
| Konfiguration | Explizit und manuell | Automatisch mit Defaults |
| Server | Externes Deployment | Embedded |
| Lernkurve | Steil, aber fundiert | Sanfter Einstieg |
| Kontrolle | Maximale Flexibilität | Konvention vor Konfiguration |
In der Praxis ist Spring Boot der Standardweg. Fast alle neuen Spring-Projekte nutzen es. Die explizite Konfiguration von Spring Framework brauchst du nur, wenn die Defaults nicht passen – und das ist selten.
Wir arbeiten mit Spring Boot. Das bedeutet: Wenig Konfiguration, schnelle Ergebnisse, Fokus auf die Konzepte statt auf Boilerplate.
Aber vergiss nicht: Unter der Haube läuft Spring Framework. Wenn du verstehst, was Spring Boot automatisiert, verstehst du auch, was passiert, wenn die Automatik mal nicht greift. Dieses Wissen macht den Unterschied zwischen jemandem, der Spring benutzt, und jemandem, der Spring versteht.