Comments (23)
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.
- Neue Version mit Jakarta EE Kompatibilität erstellen und die alte Version nur noch mit Bugfixes versehen.
- 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.
Related Issues (20)
- Support HBCI-Geschäftsvorfälle DKKKU (Umsätze) und DKKKS (Saldo) HOT 5
- NEED_PT_TANMEDIA wird nicht im ThreadedCallback behandelt HOT 1
- Problem bei Verbindung zur Deutschen Bank: 'Fehler beim Registrieren der Nutzerdaten' HOT 7
- Status Echtzeitueberweisungen? HOT 8
- org.kapott.hbci.exceptions.ParseErrorException: Fehler beim Erzeugen eines Syntax-DEs für DialogInitRes.MsgHead.SegHead.code HOT 13
- ING DiBa Connection HOT 2
- Customer's IBAN is being cut off at 27 characters HOT 1
- IBAN geht beim Parsen von KInfo6 verloren HOT 7
- Detach fork HOT 1
- Support für PushTAN 2.0 (Decoupled Verfahren) HOT 7
- Fachliche Fehlermeldungen der Bank gehen verloren HOT 1
- Anonymous: HBCI_Exception: Fehler beim Erzeugen eines HBCIHandler Objektes" HOT 2
- "Duplicate property key" in blz.properties: 75062026 HOT 1
- Client Pain Version HOT 16
- Unterstützung für verteilte Unterschriften per HBCI HOT 4
- Fehler bei Comdirect photoTan HOT 2
- PushTAN 2.0 (Decoupled) Dialog ended "erfolgreich" obwohl der Vorgang nicht in der App bestätigt wurde HOT 19
- String bei callback `NEED_PT_TANMEDIA` ist seit 3.1.80 leer (Sparkasse) HOT 3
- PushTan beim registerUser (fetchUPD) benötigt. Wie registriere ich mein Vertrauenswürdiges Gerät? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hbci4java.