Eclipse von Java 1.8 auf 17

[Thomasdausdbeih]

Moin moin,

Ich habe nur rudimentäres Wissen was Java angeht. Habe jetzt den Wechsel von 1.8 auf 17 vollzogen. Nun fliegt mir in meinem Projekt so einiges um die Ohren. Javax.xml.bind zum Beispiel. Es ist mein erster Javawechsel. Habe versucht zu googeln welche Möglichkeiten es gibt. Ist echt kompliziert für mich.
Kann ich irgendwelche libs einbinden damit mein Code weiter funktioniert oder was ist zu tun?
Ich bin für jeden Tipp dankbar.

 

[M.L.]

Javax.xml.bind ist ein Beispiel für eine Weiterentwicklung, im konkreten Fall zu Jakarta EE und jakarta.xml.bind-api: https://stackoverflow.com/questions/52502189/java-11-package-javax-xml-bind-does-not-exist

 

[Thomasdausdbeih]

Was bedeutet das für mich?
Was muss ich tun um meinen Code wieder zum laufen zu bekommen?

 

[M.L.]

wieder zum laufen zu bekommen?

Käme auch auf die Komplexität des Originalcodes an...
Mit etwas Glück ändert/ergänzt man "nur" die zu importierenden Bibliotheken (steht aber auch im Thread bei Stackoverflow)

 

[KonradN]

Um einfach einmal das, was da in Stackoverflow und dem JEP 320 steht, kurz zusammen zu fassen:

In Java 8 waren im Framework einige Namespaces, die dann mit Java 9 erst als deprecated markiert und dann mit Java 11 entfernt wurden.
javax.xml.bind ist eine davon.

Der Inhalt ist dafür in spezielle Libraries gewandert, die man nun einbinden kann. Diese sind in der JEP 320 benannt:

There are also Maven artifacts that contain just the APIs of the Java EE technologies:

• javax.xml.ws : jaxws-api (JAX-WS, plus javax.xml.soap : javax.xml.soap-api for SAAJ and javax.xml : webservices-api for Web Services Metadata)
• javax.xml.bind : jaxb-api (JAXB)
• javax.activation : javax.activation-api (JAF)
• javax.annotation : javax.annotation-api (Common Annotations)

Und das führt dann zu den möglichen Abhängigkeiten, die auch in SO Antworten benannt wurden:

<dependency>
  <groupId>javax.xml.bind</groupId>
  <artifactId>jaxb-api</artifactId>
  <version>2.3.0</version>
</dependency>
<dependency>
  <groupId>com.sun.xml.bind</groupId>
  <artifactId>jaxb-core</artifactId>
  <version>2.3.0</version>
</dependency>
<dependency>
  <groupId>com.sun.xml.bind</groupId>
  <artifactId>jaxb-impl</artifactId>
  <version>2.3.0</version>
</dependency>

Was evtl. nicht so gut beschrieben wurde:
Das ist alles aufgeteilt. Es gibt eine Spezifikation einer API. Da ist dann aber noch keine Implementation vorhanden. Und dann braucht man noch eine Implementation eben dieser API. Daher ist hier auch noch eine Implementation mit angegeben.

Was man dann noch etwas schauen könnte: Es gibt ggf. noch neuere Versionen. Aber da muss man aufpassen, denn das sind alles Dinge, die zu Java EE gehören und da gab es den Wechsel von Java EE 8 -> Jakarta EE 9, bei dem die Namespaces von javax zu jakarta umgeändert wurden. So hat die jaxb-impl 2.3.8 bereits eine Abhängigkeit zu jakarta.activation mit drin.
==> Es kann also sinnvoll sein, sich da im Detail mit der Sache zu beschäftigen um dann ggf. alles konform zu jakarta EE 9 oder Jakarta EE 10 zu machen. Das ist aber im ersten Schritt unnötig, wenn es nur darum geht, dass man wieder alles lauffähig / übersetzbar bekommen möchte.

 

[mihe7]

Es ist mein erster Javawechsel.

Kleine Info nebenbei: in der Regel laufen Versionswechsel weit geschmeidiger. Der Schritt von Java 8 auf Java 9 (bzw. das zog sich bis Java 11 hin) war allerdings wirklich heftig (weniger wegen Java selbst als vielmehr aufgrund der Tools/Libs,). Mittlerweile funktioniert das aber alles wieder recht ordentlich.

 

[Thomasdausdbeih]

Danke für Eure Worte.
Habe den Wechsel von 1.8 auf 17 jetzt hin bekommen.
Was die Javaversion angeht sind wir auf die Vorgabe der gelieferten Software angewiesen.
Und der Softwarehersteller mag auch nicht so gerne Updaten. Ich programmiere nur Dinge dazu und hatte von daher die letzten Jahre keinen Stress damit. Dafür kam jetzt alles auf einmal.