ClassNotFoundException with newer jaxb-versions and java 17 about hbci4java HOT 23 CLOSED

Die JAXB-Implementierung wurde - wenn ich mich recht erinnere - in Java 17 entfernt.
In pom.xml ist ja JAXB referenziert:

<dependency>
  <groupId>javax.xml.bind</groupId>
  <artifactId>jaxb-api</artifactId>
  <version>2.3.1</version>
</dependency>

Allerdings nur die API. Dort muss jetzt wohl auch die Implementierung explizit hinzugefügt werden.

from hbci4java.

Genau, ab Java 11 wurde JAXB entfernt.
Jedoch ist man bei der jaxb-impl auf die 2.3.6 beschränkt.
Höhere Versionen besitzen eine glassfish Implementierung und nicht mehr die sun-Implementierung.
D.h. mit höheren Versionen erhalte ich die genannte ClassNotFoundException.

from hbci4java.

Der Grund ist ein etwas anderer. GlassFish war bereits ein Projekt von SUN, als sie noch eigenständig waren, lange bevor sie von Oracle übernommen wurden. Oracle hat dann 2018 die Entwicklung von Java EE und GlassFish eingestellt und den kompletten Code der Eclipse Foundation übereignet (u.a. ist Java EE deswegen auch nicht mehr im JDK). Da die Java-Namensrechte aber weiterhin bei Oracle liegen, wurde aus Java EE bei Eclipse dann Jakarta EE. Um eine Weiterentwicklung zu gewährleisten, wurde bei der Umstellung von Jakarta EE 8 auf Jakarta EE 9 entschieden, die Namensräume von javax.* u.a. in jakarta.* umzubenennen. Darum sind die höheren Versionen (>= 3.0.0) von JAXB-API und JAXB-RI nicht mehr kompatibel und eine 2er-Version muß weiterhin verwendet werden, solange HBCI4J und Jameica nicht auf Jakarta EE 9 oder 10 umgestellt sind. Zum gegenwärtigen Zeitpunkt wäre das maximal die Version 2.3.3 bei JAXB-API und die Version 2.3.7 bei JAXB-RI.

from hbci4java.

Hallo Uhle,
ich denke Du hast das Problem gut beschrieben.
Das mit den Namensräumen macht einige Probleme mit den Abhängigkeiten.
Die prinzipielle Frage ist, wird es eine hbci4java Version geben, die Jakarta EE kompatibel ist?
Andernfalls ist man auf die alten Packages angewiesen und bekommt keine Updates mehr.
Eine Umstellung auf Jakarta EE wäre notwendig, um auch mit aktuellen Bibliotheken zusammenzuarbeiten.

from hbci4java.

Vermutlich wird mehr als nur die Ersetzung der Namensräume notwendig sein, auch wenn es wohl Tools gibt, die einen zumindest bei der Umstellung auf Jakarta EE 9 unterstützen. Aber gerade nach einer so umfassenden Änderung muß ja alles ausgiebig getestet werden.

Was die Updates bzgl. Jakarta EE 8 betrifft, so ist die angesprochene Version 2.3.7 von JAXB-RI erst im letzten Oktober erschienen. Aber ja, wer kann schon in die Zukunft sehen und vorhersagen, wie lange es solche Updates noch geben wird.

from hbci4java.

Die Umstellung auf Jakarta EE geht auch deshalb nicht "mal eben so", weil HBCI4Java nicht nur von Hibiscus verwendet wird sondern auch von einer unüberschaubaren Anzahl von Programmen - oft solche, die gar nicht öffentlich bekannt sind sondern irgendwo in den Integrationen von Zahlungsanbindungen bei Firmen stecken.
Mit einer unkoordinierten Umstellung würde man eine Menge Integrationen kaputt machen.

from hbci4java.

from hbci4java.

Gute Idee. Die Entwicklung für 4.x sollte dann aber erstmal in einem neuen Branch "4.0" neben "master" geschehen. Ich nehme pern PRs entgegen.

from hbci4java.

Das Vorgehen finde ich gut.
Bisher habe ich von anderen Bibliotheken zwei Vorgehensweisen gesehen.

1. Neue Version mit Jakarta EE Kompatibilität erstellen und die alte Version nur noch mit Bugfixes versehen.
2. Zwei Branches parallel pflegen, eine mit jakarta im Namen , der alte Branch wie bisher

from hbci4java.

Die beiden Vorgehensweisen schließen sich nicht wirklich aus. In beiden Fällen gibt es zwei separate Entwicklungszweige. Ob auf dem neuen dann "jakarta", "4.0", "next" o.ä. steht (ich hab schon so viele Varianten gesehen), ist nun wirklich nicht so wichtig. Es ist nur ein Name. Und ob auf master (Version 3.1.x) nur noch Bugfixes oder auch mal eine andere Änderung eingepflegt wird, kann vermutlich auch dann entschieden werden, wenn es dazu kommen sollte.

from hbci4java.

Oben ein Pull-Request, der auf die Version jaxb 4.0 aufsetzt und mit jakarta packages arbeitet.
Der Pull Request kann für einen neuen jakarta-Branch als Basis verwendet werden. Die Artefakt-ID sollte hierbei angepasst werden, um ein separates Package zu erhalten (z.B. hbci4j-jakarta-core)
Falls JDK8 Kompatibilität nicht mehr erforderlich ist, kann ich noch ein paar Warnings per Pull-Request entfernen.
Falls beide Branches so ähnlich wie möglich sein sollen, macht es weniger Sinn.

from hbci4java.

Hab den PR #75 in einen neuen Branch "4.0" gemerged.

from hbci4java.

Super, vielen Dank :)

from hbci4java.

@willuhn Ist es möglich für den Branch 4.0 einen Build zu machen und ins Maven-Repo zu pushen?

from hbci4java.

Ich habe ehrlich gesagt keine Ahnung, wie ich es hinkriege, einen abweichenden Branch unter einer anderen artifactId zu publishen. Hat das jemand schonmal gemacht?

from hbci4java.

Bleibt die Frage, ob die artifactId auch wirklich unbedingt geändert werden muß. Einige Bibliotheken wie z.B. JAXB API und JAXB Runtime haben nach der Namensraumumbenennung ihre bisherige artifactId auch beibehalten (jaxb-api bzw. jaxb-runtime) und nur einen Versionssprung auf die nächste Major-Revision durchgeführt (in diesem Fall 3.0.0), zumal auch hier hauptsächlich "nur" die Namensräume von javax.* in jakarta.* geändert wurden.

from hbci4java.

Die artifact-id müsste in der pom.xml der Eintrag hier sein:
hbci4j-core
Der Eintrag kann in Branch 4 angepasst werden.

In der Wildnis habe ich beide Varianten gefunden. Einige fügen -jakarta- im Namen ein, die anderen machen bei Version x einen harten Schnitt hin zu jakarta.

from hbci4java.

Die artifact-id müsste in der pom.xml der Eintrag hier sein: hbci4j-core Der Eintrag kann in Branch 4 angepasst werden.

Das weiss ich. Die Frage ist: Reicht die Änderung dort und wird das vom Repo so direkt akzeptiert oder muss das noch irgendwo registriert werden? Und kann ich ein "man release:prepare && mvn release:perform" direkt auf dem Branch machen oder muss der Branch in der pom.xml nochmal explizit angegeben werden?

In der Wildnis habe ich beide Varianten gefunden. Einige fügen -jakarta- im Namen ein, die anderen machen bei Version x einen harten Schnitt hin zu jakarta.

Einfach mit der nächsten Major-Version auf jakarte zu wechseln, brigt das Risiko, unnötig Integrationen zu brechen, da bei den Usern mit Java < 17 plötzlich zusätzliche Abhängigkeiten nötig sind, die vorher nicht erforderlich waren.

from hbci4java.

from hbci4java.

Ich fände es wie folgt am besten:

• Neue Version 4.x
• Keine Änderung der artifactId
• Umstellung auf jakarta und JDK17

Ich halte das auch für die bessere Lösung.

So macht das im Moment zb auch Spring Boot und andere. Die Zeit ist jetzt richtig.

Wenn Du jakarta im Namen hast, wirst Du das nie wieder los.

Das sehe ich persönlich genauso.

Einfach mit der nächsten Major-Version auf jakarte zu wechseln, birgt das Risiko, unnötig Integrationen zu brechen, da bei den Usern mit Java < 17 plötzlich zusätzliche Abhängigkeiten nötig sind, die vorher nicht erforderlich waren.

Das wird sich ohnehin nicht komplett vermeiden lassen, wie der ursprüngliche Problembericht hier (#73) zeigt, zumal Java EE (und damit auch JAXB) bereits seit Java 11 nicht mehr im JDK integriert ist. Ich glaube, es gibt keinen idealen Weg, um Nutzer vor eventuellen Problemen bei unbedarften Updates zu bewahren, da die Situation mit der unterschiedlichen Handhabung bei der Umstellung der einzelnen Bibliotheken auf Jakarta EE nun einmal so ist, wie sie's ist. Entweder ist es die eine oder andere Bibliotheksversion, die ggf. zu neu und damit unpassend zu den anderen ist.

Vielleicht ist es sinnvoll, auf die Umstellung von Java EE auf Jakarta EE bei der Verwendung der Bibliotheken JAXB API und JAXB Runtime in Version 4.0 von HBCI4Java zusätzlich auch in readme.md hinzuweisen.

from hbci4java.

Version 4.0.0 (jakarta.* und 3.1.67 (javax.*) sind online: https://oss.sonatype.org/#nexus-search;gav~com.github.hbci4j~hbci4j-core~~~~kw,versionexpand

from hbci4java.

Super, vielen Dank! :)

from hbci4java.

Wow! Ich hatte gerade alles andere bei uns auf jakarta umgestellt und wollte mich jetzt hier nützlich machen. Danke, Olaf!

from hbci4java.