Ich möchte da erst einmal allgemeiner antworten:
Jede Umstellung ist mit Aufwänden und Risiken verbunden, was dann aus unternehmerischer Sicht in Form von Kosten zu handhaben ist. Wie immer, muss man Kosten rechtfertigen und damit stellt sich die Frage: Was für Vorteile bringt es einem?
Das man in der Software Entwicklung seine Software warten muss und dabei dann auch Migrationen durchzuführen hat, ist klar. Das soll nicht der Punkt der Diskussion sein. Also bleibt tatsächlich, die einzelnen Optionen zu betrachten.
Ganz grob wäre sowas dann:
- Jakarta EE lassen. Dann bliebe eine Migration auf Jakarta EE 10 oder so. Müsste man wie immer im Detail schauen, was da so alles an Änderungen gewesen ist. Dann kann man den Aufwand / Umfang schätzen.
- Umstellung auf Spring Boot. Auch hier ist dann natürlich zu analysieren, was es da so an Änderungen gibt. Das kann man so ganz pauschal nicht sagen - Spring Boot und Jakarta EE haben funktional große Überlappungen, so dass sowas denkbar sein sollte.
- einzelne Technologien können getauscht werden. Also wir schmeißen Primefaces raus und nutzen da was Neues... (Das geht generell egal ob Jakarta EE oder Spring Boot) ...
Wenn man das dann bewerten will, dann sehe ich mehrere Punkte:
a) Aufwand - hier müsste man wirklich einfach mal im Detail schauen, was notwendig ist. Da können dann auch kleine Proof of Concepts ins Spiel kommen. Sprich: Hast Du mal eine Spring Boot Anwendung gebaut mit EclipseLink und PrimeFaces? Was ändert sich da zu dem bisherigen Code, den ihr aktuell habt?
b) Know How - ein wichtiger Punkt ist immer das KnowHow. Du baust jetzt etwas und das soll auch sicher gepflegt werden. Was für KnowHow habt ihr? Gibt es Kollegen, die Spring Boot kennen?
c) Commitment - steht das Team dahinter? Du willst jetzt etwas und alle anderen wollen das nicht? Kann schnell ganz fatal sein. Man will ja an einem Strang ziehen.
d) Risiko - hängt auch am KnowHow: Wie groß ist die Chance, dass es gegen die Wand geht? Wird das Vorhaben klappen?
Unter diesen Gesichtspunkten würde ich das etwas bewerten wollen. Und dann sehe ich die Aussage:
Da ich vor sechs Jahren an SpringBoot gescheitert bin, habe ich vor zum Umbau es noch einmal zu probieren
Das ist dann evtl. ein Proof of Concept. Probier einmal und schau, was wie geht. Aber Du bist an Spring Boot gescheitert, kennst Dich da also nicht aus und dann willst Du heraus finden, wie Du den Bestandscode am besten auf Spring Boot umstellst? Das klingt nicht gut. Das ist nicht gut für Dich, denn die Gefahr ist groß, dass Du böse auf die Nase fällst und du schlicht demotiviert wirst. Und die Chancen für ein gutes Ergebnis sind auch nicht so gut. Du solltest erst einmal Spring Boot im Detail kennen lernen. Dann kann man mehr dazu nehmen und schauen, wie Primefaces verwendet werden kann ... oder wie EclipseLink verwendet werden kann. Klar - du wirst ggf. irgendwas aufbauen können - Baeldung hat Artikel zu beiden Themen oder chatgpt wird bestimmt irgend was liefern. Aber da fehlt dann doch massiv das Verständnis, was da eigentlich passiert.... Und dann sind doch Folgeprobleme vorprogrammiert - du willst ja am Ende ja nicht nur, dass es technisch überhaupt funktioniert sondern Du willst auch so Dinge wie Spring Security und so verstanden haben.
Das wäre so der Roman, den ich da beisteuern würde. Wichtig: Das ist kein "Lass es". Sondern nur ein: "Verstehe die Problematik und mache es vernünftig". Also ggf. erst einmal Spring Boot verstehen. Spring Security dürfte auch wichtig sein und sollte verstanden worden sein. Und dann kann man nach und nach mehr dazu nehmen ... auch Primefaces oder EclipseLink.
