Franz-Martin nimmt das Steuer – Oktober 2025
📊 Die Zahlen sprechen eine klare Sprache
Manchmal passieren Dinge still und leise. Ohne großes Getöse. Ohne Marketing-Spektakel. Und doch markieren sie einen Wendepunkt.
Die Eclipse Foundation hat die Ergebnisse des Jakarta EE Developer Survey 2025 veröffentlicht. Über 1.700 Entwickler haben teilgenommen – 20% mehr als im Vorjahr. Die Zahlen sind eindeutig: Jakarta EE liegt mit 58% erstmals vor Spring (56%).
Ich navigiere seit vier Jahrzehnten durch die Enterprise-Java-Welt. Ich habe Paradigmenwechsel kommen und gehen sehen. Dieser hier? Der ist real.
🚢 Was bedeutet das für unsere Navigation?
Java 21 setzt sich durch – schneller als erwartet
43% der Entwickler nutzen bereits Java 21. Ein Sprung von 30% im Jahr 2024. Das ist keine langsame Adoption mehr – das ist Momentum.
Gleichzeitig sehe ich den Rückgang bei Java 8 und 17. Java 11 erlebt ein leichtes Comeback (37%). Das erinnert mich an LTS-Strategie-Diskussionen aus den 2000ern. Manche Dinge ändern sich nie.
Cloud-Strategien: Zwischen Fortschritt und Unsicherheit
22% setzen auf Lift-and-Shift. Soweit nichts Neues. Aber: 20% haben 2025 noch keine klare Cloud-Strategie – fast doppelt so viele wie im Vorjahr.
Das ist ein Signal.
Ich habe in meiner Karriere gelernt: Wenn die Unsicherheit wächst, während die Technologie reift, dann liegt das nicht an der Technologie. Es liegt an den Prozessen, den Teams, den Entscheidungswegen.
Real talk: Cloud-Migration ist kein Tech-Problem mehr. Es ist ein Organisations-Problem.
Digitale Souveränität – Das vergessene Thema
Was in der Umfrage nicht explizit steht, aber zwischen den Zeilen mitschwingt: Vendor Lock-in und digitale Souveränität.
Wenn wir von „Cloud“ sprechen, denken die meisten automatisch an die „Big 3“: AWS, Azure, Google Cloud. Das ist verständlich – aber nicht alternativlos.
Gerade im europäischen Raum gibt es starke Alternativen:
- IONOS (Deutschland) – Größter europäischer Hosting-Anbieter
- OVHcloud (Frankreich) – Europas größter Cloud-Provider
- Hetzner (Deutschland) – Solide Cloud-Infrastruktur mit fairen Preisen
- Open Telekom Cloud (Deutschland/T-Systems)
- plusserver (Deutschland) – DSGVO-konform, europäische Rechenzentren
Warum ist das wichtig?
- DSGVO & Datenschutz: Daten bleiben in Europa
- Cloud Act & Patriot Act: US-Behörden haben Zugriff auf Daten bei US-Anbietern
- Vendor Lock-in: Abhängigkeit von einem einzelnen Hyperscaler
- Kosten: Europäische Anbieter sind oft günstiger
- Support: Deutscher Support, europäische Zeitzonen
Jakarta EE und Open-Source-Application-Server (WildFly, Open Liberty, Payara) laufen überall. Du bist nicht auf proprietäre Services angewiesen. Das ist echte Freiheit.
⚓ Jakarta EE 11 – Der stille Gewinner
18% der Befragten setzen bereits auf Jakarta EE 11, obwohl die finale Version erst nach der Umfrage erschien. Das zeigt mir zwei Dinge:
- Early Adopters sind zurück: Die Community traut sich wieder, neue Versionen zu testen
- Vertrauen ist da: Jakarta EE ist kein Experiment mehr – es ist Production-ready
Besonders interessant: Kleinere Unternehmen (<500 Mitarbeiter) sind schneller dabei als Konzerne. Wie so oft. Agilität schlägt Größe.
🧭 Was die Community wirklich will
Die Prioritäten haben sich verschoben:
- Cloud-native Readiness steht ganz oben
- Schnellere Implementierung von Jakarta-EE-Spezifikationen in App-Servern
- Praxistaugliche Kubernetes-Features: Health Checks, Secrets-Management, Telemetrie
Das sind keine Marketing-Buzzwords mehr. Das sind Anforderungen aus dem echten Leben. Aus Production. Aus Teams, die Deployments um 3 Uhr morgens machen und am nächsten Tag verstehen wollen, warum etwas schiefging.
Ich sehe hier eine Parallele zu den frühen 2000ern: Damals wollten alle J2EE, aber niemand wusste genau, wie. Heute wollen alle Cloud-native, aber die Strategien variieren stark.
Der Unterschied? Heute haben wir die Werkzeuge. Heute haben wir Standards. Heute haben wir Jakarta EE 11.
🎯 Meine Navigation für 2025
Wenn ich die Daten interpretiere – und ich tue das seit 40 Jahren – dann sehe ich drei klare Richtungen:
1. Java 21 ist die neue Baseline
Wer heute auf Java 8 bleibt, bleibt nicht aus technischen Gründen. Legacy-Systeme, Compliance, interne Prozesse – das sind die wahren Blocker. Nicht die Technologie.
Rat: Macht einen Plan. Migriert schrittweise. Aber macht einen Plan.
2. Jakarta EE und Spring sind Partner, keine Rivalen
Das ist kein Wettkampf. Seit Spring Boot 3.0 (November 2022) basiert Spring vollständig auf Jakarta EE 9+ statt auf dem alten Java EE. Der Namespace-Wechsel von javax.* zu jakarta.* war kein kleines Update – es war ein klares Bekenntnis zur Jakarta EE Platform.
Real talk: Wer heute glaubt, Jakarta EE und Spring seien Konkurrenten, hat nicht verstanden, wie das Ökosystem funktioniert. Spring nutzt Jakarta EE Spezifikationen (Servlet API, JPA, Bean Validation, CDI, JAX-RS, JAX-B, JAX-P und viele mehr) als Foundation und bietet darauf aufbauend eigene Abstraktionen und Convenience-Features.
Die Frage ist nicht „Jakarta EE oder Spring“, sondern „Jakarta EE pur oder Jakarta EE mit Spring-Abstraktionen“.
3. Cloud-native braucht klare Strategien
20% Unsicherheit bei Cloud-Strategien ist ein Warnsignal. Nicht für die Technologie – für die Organisation.
Tipp: Wenn ihr keine Strategie habt, fangt klein an. Ein Service. Ein Team. Ein Deployment-Pipeline. Lernt. Iteriert. Skaliert.
📜 Captain’s Log: Reflexion
Ich habe drei große Paradigmenwechsel in meiner Karriere erlebt:
- 1990er: Client/Server → Web
- 2000er: J2EE → Lightweight Frameworks
- 2020er: Monolithen → Cloud-native
Jedes Mal dachten alle, die Welt geht unter. Jedes Mal haben wir uns angepasst.
Jakarta EE 11, Java 21, Cloud-native – das sind keine Bedrohungen. Das sind Werkzeuge. Und wie bei allen Werkzeugen: Es kommt darauf an, wie man sie einsetzt.
Die Community hat gesprochen. Die Zahlen sind klar. Der Paradigmenwechsel ist da.
Die Frage ist: Bist du bereit?
Franz-Martin
Captain der Java Fleet
„Navigate, don’t dictate“
🔗 Weiterführende Links
- Jakarta EE Developer Survey 2025 – Eclipse Foundation
- Jakarta EE 11 Spezifikation
- Java 21 Features Overview
FAQ:
Q: Sollten wir von Spring zu Jakarta EE wechseln?
A: Diese Frage ist falsch gestellt. Seit Spring Boot 3.0 (November 2022) basiert Spring vollständig auf Jakarta EE 9+. Wenn du Spring Boot 3.x nutzt, nutzt du bereits Jakarta EE – nur mit Spring’s Abstraktionen darüber. Die Frage sollte lauten: „Brauchen wir Spring’s Abstraktionen, oder reicht uns Jakarta EE pur mit einem Application Server wie WildFly, Open Liberty oder Payara?“ Beide Wege sind valide. Es kommt auf dein Team, deine Anforderungen und deine bestehende Architektur an.
Q: Java 21 – lohnt sich der Upgrade-Aufwand?
A: Ja. Virtual Threads allein sind den Aufwand wert. Pattern Matching, Records, Text Blocks – das sind Produktivitätsgewinne. Aber: Plant es vernünftig. Migriert schrittweise. Testet gründlich.
Q: Wie gehen wir mit der Cloud-Unsicherheit um?
A: Fangt klein an. Proof of Concept. Ein Service. Lernt. Iteriert. Lasst euch nicht von der Komplexität lähmen. Cloud-native ist kein Alles-oder-Nichts-Spiel.
Q: Muss es immer AWS/Azure/GCP sein?
A: Nein! Gerade im europäischen Raum gibt es starke Alternativen: IONOS, OVHcloud, Hetzner, Open Telekom Cloud, plusserver. Vorteile: DSGVO-konform, Daten bleiben in Europa, kein Cloud Act, oft günstiger, deutscher Support. Jakarta EE läuft überall – du bist nicht an proprietäre Cloud-Services gebunden. Das ist digitale Souveränität. Überlegt euch genau: Brauche ich wirklich AWS Lambda, oder reicht mir ein Standard-Kubernetes-Cluster bei einem europäischen Anbieter?
Q: Was bedeutet „Spring basiert auf Jakarta EE“?
A: Spring Boot 3.x (seit November 2022) nutzt Jakarta EE 9+ Spezifikationen als technische Foundation: Servlet API (jakarta.servlet.*), JPA (jakarta.persistence.*), Bean Validation (jakarta.validation.*), JAX-RS (jakarta.ws.rs.*), JAX-B (jakarta.xml.bind.*), JAX-P (jakarta.xml.*) und weitere. Der große Namespace-Wechsel von javax.* zu jakarta.* war nicht nur kosmetisch – es war Springs klares Commitment zur Jakarta EE Platform. Spring ist also kein Ersatz für Jakarta EE, sondern ein Framework, das auf Jakarta EE aufsetzt und zusätzliche Abstraktionen, Convenience-Features und ein umfangreiches Ökosystem bietet.
Q: Ist Lift-and-Shift eine gute Cloud-Strategie?
A: Zuerst: Was ist Lift-and-Shift? Du nimmst deine bestehende Anwendung (z.B. auf einem On-Premise Server) und „hebst“ sie 1:1 in die Cloud – ohne große Code-Änderungen. Aus einem physischen Server wird eine VM in AWS/Azure/GCP. Für den Anfang: Ja, das ist okay. Du bist schnell in der Cloud, Risiko ist niedrig, Team muss nicht umlernen. Als langfristige Strategie? Nein. Lift-and-Shift bringt dich in die Cloud, aber du nutzt die Cloud-Vorteile nicht (Auto-Scaling, Managed Services, Pay-per-Use). Du zahlst Cloud-Preise für On-Premise-Architektur. Nächster Schritt sollte sein: Re-Architecting. Cloud-native Features nutzen. Aber: Besser Lift-and-Shift als gar nicht starten.
Teil der Java Fleet Captain’s Logs – Navigating Enterprise Java since 1995
PS: Die vollständigen Survey-Daten findet ihr auf der Eclipse Foundation Website. Lesenswert!
🏷️ Tags
#JakartaEE #Java21 #EnterpriseJava #SpringBoot #CloudNative #Kubernetes #EclipseFoundation #JavaDevelopment #Microservices #CloudMigration #ApplicationServer #ModernJava #DeveloperSurvey #JavaFleet #CaptainsLog #DigitaleSouveränität #EuropeanCloud #DSGVO
