Wer wissen will, ob der nächste Java-Dienst mit Spring Boot oder Quarkus entstehen soll, findet vor allem Balkendiagramme mit Startzeiten. Die Zahlen stimmen meistens. Nur beantworten sie eine Frage, die kaum jemand hat.
Die Gemeinsamkeiten sind größer als die Unterschiede
Aktuelle Java-Versionen, Container, Kubernetes, Testcontainers, Observability über Micrometer und OpenTelemetry: alles auf beiden Seiten. Auch GraalVM Native Images baut Spring Boot längst, über Native Build Tools oder Cloud Native Buildpacks. Das häufigste Argument für einen Wechsel ist damit keins mehr. Die echten Unterschiede liegen im Laufzeitmodell, im Ökosystem — und im Aufwand, der zwischen heute und dem Zielzustand steht.
Spring-Kompatibilität ist nicht Spring-Unterstützung
Quarkus bringt Kompatibilitätsextensions für Spring DI, Spring Web, Spring Data
JPA und einige mehr. Sie erlauben vertraute Annotationen — aber sie starten
keinen Spring Application Context, und es läuft keine Spring-Infrastrukturklasse.
Die Spring-Klassen werden nur gelesen, um Metadaten auszuwerten. Daraus folgen
konkrete Lücken: @Conditional wird ignoriert, weil Dependency Injection schon
beim Bauen aufgelöst wird. QueryDSL fehlt. Und QueryByExample scheitert nicht
beim Kompilieren, sondern erst zur Laufzeit.
Wer beides gleichsetzt, plant eine Migration von zwei Wochen und bleibt an einer einzigen Repository-Methode hängen.
Werkzeuge nehmen die Fleißarbeit ab, nicht die Entscheidung
Der Forschungsbenchmark ScarfBench hat 204 Migrationsaufgaben zwischen Spring, Jakarta EE und Quarkus untersucht — und dabei nicht geprüft, ob der erzeugte Code kompiliert, sondern ob sich die Anwendung hinterher noch genauso verhält. Gegen über 1300 Tests bleiben selbst die stärksten Agenten unter zehn Prozent Erfolg.
Mehr dazu
Welche sieben Kriterien du stattdessen durchgehst und wie daraus ein Entscheidungsprofil statt einer Punktzahl wird, zeigt das kostenlose Kurzmodul Sieben Entscheidungskriterien — mit Video und Kapitelübersicht.