Versionsstrategie: warum zwei Etappen statt einer

Das Problem

Der urspruengliche Wunsch war "Java 11 und Spring Boot und Jakarta EE weg von Java EE" - alles gleichzeitig. Das geht technisch nicht:

• Spring Boot 2.7.x ist die letzte Boot-Linie, die Java 8/11 unterstuetzt. Sie nutzt aber noch durchgaengig den javax.*-Namespace (Jakarta EE 8) - javax.persistence, javax.servlet, javax.validation, usw.
• Spring Boot 3.x ist die erste Linie mit jakarta.*-Namespace (Jakarta EE 9+). Sie setzt Java 17 zwingend voraus - es gibt keine Spring-Boot-3-Version, die auf Java 11 laeuft.

Es gibt also keine Kombination "Java 11 + aktuelles Spring Boot + jakarta.*". Diese Einschraenkung kommt nicht von Spring, sondern folgt direkt aus der Java-Plattform-Modulhistorie (Jakarta EE 9 war die Namespace-Umbenennung nach der Uebergabe von Java EE an die Eclipse Foundation; Spring Boot 3 wurde bewusst zeitgleich mit dem Java-17-LTS-Release geschnuert).

Die gewaehlte Loesung: zwei getrennte, dokumentierte Etappen

Etappe A ist der groessere konzeptionelle Bruch: weg vom EJB-Container, hin zu Spring als Programmiermodell (Dependency Injection, Transaktionsverwaltung, Deployment-Modell). Der javax.*-Namespace bleibt dabei absichtlich noch bestehen, weil er in dieser Etappe nicht die eigentliche Baustelle ist.

Etappe B ist demgegenueber ein weitgehend mechanischer Schritt: Java-Version und Spring- Boot-Major-Version anheben, die wenigen verbleibenden javax.*-Imports (in novaris-policy-core-modern sind das nur javax.persistence.* fuer die JPA-Entities) auf jakarta.persistence.* umstellen. Weil die neuen Module von Anfang an schlank gegen Spring-Abstraktionen geschrieben sind (kein javax.ejb, kein javax.jms mehr im Zielbild), ist diese zweite Etappe deutlich kleiner als der erste Schritt.

Wann Etappe B stattfindet

Laut Phasenroadmap (04-phasenroadmap.md) in Migrationsphase M4, unmittelbar vor der Containerisierung fuer OpenShift - ein sinnvoller Schnittpunkt, weil an dieser Stelle ohnehin neue Build-/Container-Artefakte entstehen (kein zusaetzlicher "Wegwerf-Build" auf Java 11 noetig, der kurz danach schon wieder ersetzt wird).

Etappe B: Ergebnis (Migrationsphase M4)

Durchgefuehrt wie geplant, mit einem echten, im Vorfeld nicht vorhergesehenen Fund: Spring Framework 6 (Basis von Spring Boot 3) hat org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean komplett entfernt - nicht nur umbenannt oder verschoben, sondern ersatzlos gestrichen, weil JAX-WS seit Jakarta EE 9 kein Bestandteil der Plattform mehr ist. Das war kein reiner javax->jakarta-Namespace-Wechsel, sondern der Wegfall eines kompletten Spring-Bausteins. Ersatz: direkter Aufbau mit jakarta.xml.ws.Service.create(wsdlUrl, serviceQName).getPort(portQName, PortInterface.class) in BillingClientConfig - siehe novaris-policy-core-modern/README.md fuer die Details und den Nachweis, dass der jakarta-basierte Client weiterhin klaglos mit dem unveraendert javax-basierten novaris-billing-soap-Server spricht.

Alle 14 Tests des modernen Reactors liefen nach dem Sprung unveraendert gruen; die App-Startzeit sank spuerbar (ca. 60s auf Java 11/Boot 2.7 -> ca. 11s auf Java 17/Boot 3.2 fuer novaris-policy-core-modern).

Praktische Konsequenz fuer bereits bestehenden Code

novaris-common-modern und novaris-policy-core-modern (Migrationsphase M1) sind bewusst so geschrieben, dass der Etappe-B-Sprung spaeter moeglichst wenig Reibung erzeugt:

• Keine direkten javax.ejb/javax.jms-Abhaengigkeiten mehr im Anwendungscode (nur noch javax.persistence fuer JPA-Entities - der einzige Namespace-Rest, der in Etappe B angefasst werden muss).
• Messaging ist bereits auf Kafka statt JMS ausgelegt (03-messaging-jms-zu-kafka.md) - kein Zwischenschritt "erst JMS in Spring nachbauen, dann durch Kafka ersetzen".