Ersetzungen für veraltete JPMS-Module durch Java EE-APIs


183

Java 9 hat sechs Module, die Java EE-APIs enthalten, veraltet und werden bald entfernt :

  • java.activation mit javax.activationPaket
  • java.corba mit javax.activity, javax.rmi, javax.rmi.CORBA, und org.omg.*Pakete
  • java.transaction mit javax.transactionPaket
  • java.xml.bind mit allen javax.xml.bind.*Paketen
  • java.xml.ws mit javax.jws, javax.jws.soap, javax.xml.soap, und alle javax.xml.ws.*Pakete
  • java.xml.ws.annotation mit javax.annotationPaket

Welche gepflegten Artefakte von Drittanbietern stellen diese APIs bereit? Es spielt keine Rolle, wie gut sie diese APIs bereitstellen oder welche anderen Funktionen sie bieten - alles, was zählt, ist, dass sie ein Ersatz für diese Module / Pakete sind?

Um das Sammeln von Wissen zu vereinfachen, antwortete ich mit dem, was ich bisher wusste, und machte die Antwort zu einem Community-Wiki. Ich hoffe, die Leute werden es erweitern, anstatt ihre eigenen Antworten zu schreiben.


Bevor Sie abstimmen, um zu schließen:

  • Ja, es gibt bereits einige Fragen zu einzelnen Modulen, und eine Antwort auf diese Frage würde diese Informationen natürlich duplizieren. Aber AFAIK, es gibt keinen einzigen Punkt, um über all dies zu lernen, was meiner Meinung nach sehr wertvoll ist.
  • Fragen, die nach Bibliotheksempfehlungen fragen, werden normalerweise als nicht zum Thema gehörend angesehen, da "sie dazu neigen, meinungsgebundene Antworten und Spam anzulocken", aber ich denke nicht, dass dies hier zutrifft. Der Satz gültiger Bibliotheken ist klar abgegrenzt: Sie müssen einen bestimmten Standard implementieren. Darüber hinaus ist nichts anderes wichtig, daher sehe ich kein großes Risiko für Meinungen und Spam.

6
Sie finden meistens alle, die verschoben werden, unter github.com/javaee und Links zu einigen Details unter JEP 320: Entfernen Sie die Java EE- und CORBA-Module
Naman

Siehe auch diesen Artikel vom 14.05.2018 in InfoWorld, Java-Roadmap: Eclipse's Jakarta EE Enterprise Java nimmt Gestalt an von Paul Krill. Untertitel: Die Eclipse Foundation skizziert die 39 Projekte, aus denen sich das neue Cloud-native, Microservices-freundliche Java-Unternehmen zusammensetzt, und wie sich GlassFish entwickeln wird
Basil Bourque

2
Aus JDK 11 wurde es entfernt. Wenn Sie jdk 9 oder höher verwenden, ist es besser, die Abhängigkeit direkt hinzuzufügen, als die Art "--add-modules java.xml.bind" zu verwenden
Anver Sadhat

Antworten:


205

Verwenden Sie anstelle der veralteten Java EE-Module die folgenden Artefakte.

JAF ( java.activation )

JavaBeans Activation Framework (jetzt Jakarta Activation ) ist eine eigenständige Technologie (verfügbar in Maven Central):

<dependency>
    <groupId>com.sun.activation</groupId>
    <artifactId>jakarta.activation</artifactId>
    <version>1.2.2</version>
</dependency>

( Quelle )

CORBA ( java.corba )

Aus JEP 320 :

Es wird keine eigenständige Version von CORBA geben, es sei denn, Dritte übernehmen die Wartung der CORBA-APIs, der ORB-Implementierung, des CosNaming-Anbieters usw. Die Wartung durch Dritte ist möglich, da die Java SE-Plattform unabhängige Implementierungen von CORBA unterstützt. Im Gegensatz dazu wird die API für RMI-IIOP ausschließlich in Java SE definiert und implementiert. Es wird keine eigenständige Version von RMI-IIOP geben, es sei denn, ein dedizierter JSR wird gestartet, um es zu verwalten, oder die Verwaltung der API wird von der Eclipse Foundation übernommen (der Übergang der Verwaltung von Java EE von JCP zu Eclipse Foundation umfasst GlassFish und seine Implementierung von CORBA und RMI-IIOP).

JTA ( java.transaction )

Standalone-Version:

<dependency>
    <groupId>jakarta.transaction</groupId>
    <artifactId>jakarta.transaction-api</artifactId>
    <version>1.3.3</version>
</dependency>

( Quelle )

JAXB ( java.xml.bind )

Seit Java EE in Jakarta EE umbenannt wurde , wird JAXB jetzt durch neue Artefakte bereitgestellt:

<!-- API -->
<dependency>
    <groupId>jakarta.xml.bind</groupId>
    <artifactId>jakarta.xml.bind-api</artifactId>
    <version>2.3.3</version>
</dependency>

<!-- Runtime -->
<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-impl</artifactId>
    <version>2.3.3</version>
    <scope>runtime</scope>
</dependency>

JAXB-Referenzimplementierungsseite .

schemagenund xjckann dort auch als Teil einer eigenständigen JAXB-Distribution heruntergeladen werden.

Siehe auch verknüpfte Antwort .

JAX-WS ( java.xml.ws )

Referenzimplementierung:

<!-- API -->
<dependency>
    <groupId>jakarta.xml.ws</groupId>
    <artifactId>jakarta.xml.ws-api</artifactId>
    <version>2.3.3</version>
</dependency>

<!-- Runtime -->
<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-rt</artifactId>
    <version>2.3.3</version>
</dependency>

Download der eigenständigen Distribution (enthält wsgenund wsimport).

Allgemeine Anmerkungen ( java.xml.ws.annotation )

Java Commons Annotations (verfügbar in Maven Central):

<dependency>
    <groupId>jakarta.annotation</groupId>
    <artifactId>jakarta.annotation-api</artifactId>
    <version>1.3.5</version>
</dependency>

( Quelle )


Was tun, wenn ein Modul jax-wssowohl aus JDK als auch aus der com.sun.xml.wsAbhängigkeit liest ?
nllsdfx

1
Ich bin mir nicht sicher, was genau du fragst. Welches Modul liest jax-ws? Wenn Sie java.xml.ws im Moduldiagramm und com.sun.xml.ws:jaxws-ri im Klassenpfad haben, wird letzteres ignoriert (aufgrund von geteilten Paketen ).
Nicolai

Nun, ich möchte com.sun.xml.ws:jaxws-rianstelle von java.xml.wsin meinem Modul verwenden, da letzteres veraltet ist und entfernt wird. Und ich habe die Abhängigkeit zu meiner POM-Datei hinzugefügt und der Fehler "Modul xyz liest das Paket 'javax.xml.ws' aus 'java.xml.ws' und 'java.xml.ws'" wurde angezeigt.
nllsdfx

Es sieht so aus, als ob das Modul java.xml.ws doch aufgelöst wird, möglicherweise aufgrund eines --add-modulesoder weil einige andere Module es erfordern. Können Sie eine neue Frage öffnen, damit wir sie uns ansehen können?
Nicolai

1
Das ist richtig. Zwei Details: (1) Wenn kein explizites Modul (dh eines mit einer Moduldeklaration) von JAXB abhängt, können Sie sie dennoch im Klassenpfad platzieren, wo geteilte Pakete keine Rolle spielen. (2) Die Befehlszeilenoption --patch-modulekann die Aufteilung korrigieren.
Nicolai

25

JAXB (java.xml.bind) für JDK9

Funktioniert perfekt in meinen Desktop-Anwendungen auf jdk9 / 10 EA

<properties>
    <jaxb-api.version>2.3.0</jaxb-api.version>
</properties>

<!-- JAXB 2.3.0 for jdk9+ -->
<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>${jaxb-api.version}</version>
</dependency>
<dependency>
    <groupId>org.glassfish.jaxb</groupId>
    <artifactId>jaxb-runtime</artifactId>
    <version>${jaxb-api.version}</version>
</dependency>
<!-- JAXB needs javax.activation module (jdk9) -->
<dependency>
    <groupId>javax.activation</groupId>
    <artifactId>javax.activation-api</artifactId>
    <version>1.2.0</version>
</dependency>

5
Danke, das aber für mich auf Java 10. gearbeitet, dass die Verwendung einer einzigen Eigenschaft für die Versionsnummer 2.3.0für beide jaxb-apiund jaxb-runtimeist keine gute Idee. Die Glassfish-Laufzeit ist derzeit aktiv,2.3.0.1 während die API aktiv bleibt 2.3.0. Ich schlage vor, das propertiesElement vollständig in der Antwort zu löschen und jede Versionsnummer dependencyeinzeln separat zu codieren .
Basil Bourque

Meine Empfehlung: <dependencyManagement>Importieren Sie in die org.glassfish.jaxb:jaxb-bomStückliste in einer bestimmten Version (die neueste Version ist jetzt 2.3.0.1), und geben Sie dann im aktuellen <dependencies>Abschnitt keine Version für entweder jaxb-apioder an jaxb-runtime. Die Versionsnummer wird aus der Stückliste abgerufen, um sicherzustellen, dass sie immer synchron sind und gemeinsam aktualisiert werden.
AndrewF

2
JAXB 2.3. [0 | 1] funktioniert nicht mehr für Java 11! Siehe github.com/eclipse-ee4j/jaxb-api/issues/78
col.panic

9

Ich musste JAX-WS (java.xml.ws) und JAXB (java.xml.bind) für meine Spring Boot 2-basierte Anwendung ersetzen und erhielt diese JARs (Gradle Build):

// replacements for deprecated JDK module java.xml.ws
runtimeOnly 'javax.xml.ws:jaxws-api:2.3.0' // javax.xml.ws.* classes
runtimeOnly 'javax.jws:jsr181-api:1.0-MR1' // for javax.jws.* classes

// replacement for deprecated JDK module java.xml.bind
runtimeOnly 'javax.xml.bind:jaxb-api'
runtimeOnly 'org.glassfish.jaxb:jaxb-runtime:2.3.0.1'
runtimeOnly 'org.glassfish:javax.json:1.1.2'
runtimeOnly 'org.eclipse:yasson:1.0.1'

(Möglicherweise benötigen Sie einen compileanderen Bereich, der runtimeOnlyuns gereicht hat.)

Ich bemerkte , dass https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-core als „Alt“ beschrieben und mit dieser Antwort für ging org.glassfishbasierte Sachen , die in gebracht org.eclipse.yassonals auch.

Jetzt ist es eine wirklich chaotische Situation, es funktioniert, aber wie sollte jemand sicher sein, dass es der beste Ersatz ist, oder?


Wir benutzen auch Gradle und ich bin nicht weitergekommen. Versucht, die Maven-Lösungen in Gradle zu übersetzen, aber kein Erfolg. Ihr Beispiel funktioniert für mich (verwendete Kompilierung, obwohl nicht bereitgestellt, das Projekt, das ich zu migrieren versuche, verwendet vertx). Vielen Dank für das Teilen und in der Tat hoffe ich auch, dass es bald einige Klarstellungen bezüglich Gradle geben wird :)
Lars

Bitte beachten Sie, dass sich die Situation ziemlich schnell entwickelt - erst kürzlich habe ich ein anderes Projekt auf Spring Boot 2.2 verschoben, wo Jakarta-APIs eine größere Rolle spielen, aber wir brauchen auch noch Implementierungen. Dafür benutze ich immer noch org.glassfish. * Zeug. Wenn ich ein Spring Boot-Projekt verwende, überprüfe ich in der Regel den Anhang zu den Abhängigkeitsversionen und passe ihn so weit wie möglich an (ändern Sie die aktuelle Version in die von Ihnen benötigte Version): docs.spring.io/spring-boot/docs/current/reference/html/ …
Jungfrau47

8

Es scheint, dass jaxws-ri transitiv von commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852 abhängt, das anscheinend im Repository http://download.eclipse.org/rt/eclipselink/maven.repo zu finden ist


1
Wahrscheinlich, weil es eher für einen Kommentar als für eine Antwort geeignet war. Konnten Sie das Problem trotzdem beheben? Ich scheine nicht in der Lage zu sein, die Abhängigkeit abzurufen. mvn -U clean installsagt immer wieder Could not find artifact commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852.
Zyl

1
Ich bin kein Maven-Experte, aber es scheint, dass er commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852 findet, wenn in pom.xml keine Repositorys deklariert sind. Wenn in pom.xml Repositorys vorhanden sind (wie Spring-Snapshot), muss auch download.eclipse.org/rt/eclipselink/maven.repository hinzugefügt werden , z. B. <Repositor> <id> meine-ID </ id> <Name> eclipse-repo </ name> <url> download.eclipse.org/rt/eclipselink/maven.repo </ url > </ repository> ps. Ich hätte Kommentar statt Antwort hinzugefügt, wenn mein Ruf groß genug wäre :)
theNikki1

2
Ich konnte es zum Laufen bringen, musste aber auch einen Spiegel aus meiner settings.xml entfernen. Nach weiterer Prüfung kann ich jedoch nicht reproduzieren, wie dies ein Ersatz für das veraltete Paket ist. Stattdessen fand ich diese Abhängigkeit, die gut funktioniert:<dependency> <groupId>javax.jws</groupId> <artifactId>jsr181-api</artifactId> <version>1.0-MR1</version> </dependency>
Zyl

Ich konnte das Paket einfach ausschließensdo-eclipselink-plugin
Joseph Lust

2

Nur eine kleine Variation (Verbesserung) der obigen Antworten - hier nur für JAXB veranschaulicht. Man kann die Abhängigkeiten mit dem runtimeBereich hinzufügen und nur dann, wenn dies effektiv benötigt wird (dh beim Erstellen für die Ausführung in einer JRE mit Version> = 9 --- hier ist v11 beispielhaft dargestellt):

<profile>
        <id>when-on-jdk-11</id>
        <activation>
            <jdk>11</jdk>
        </activation>

        <properties>
            <!-- missing artefacts version properties -->
            <jaxb-api.version>2.3.1</jaxb-api.version>
            <jaxb-impl.version>2.3.2</jaxb-impl.version> <!-- one might let it the same with the jaxb-api.version -->
        </properties>

        <dependencies>
            <!-- runtime dependencies to avoid JAXB related CNF exceptions when running on Java 11 (e.g.: ClassNotFoundException: javax.xml.bind.annotation.XmlType) -->
            <dependency>
                <groupId>javax.xml.bind</groupId>
                <artifactId>jaxb-api</artifactId>
                <version>${jaxb-api.version}</version>
                <scope>runtime</scope>
            </dependency>
            <dependency>
                <groupId>org.glassfish.jaxb</groupId>
                <artifactId>jaxb-runtime</artifactId>
                <version>${jaxb-impl.version}</version>
                <scope>runtime</scope>
            </dependency>
        </dependencies>
    </profile>

1

Ich habe mit den meisten der oben beschriebenen Vorschläge mit JDK 11.0.3 experimentiert und war nicht erfolgreich. Die einzige Lösung, die ich schließlich gefunden habe, ist die folgende. Vielleicht gibt es auch andere Optionen, die funktionieren, aber es scheint, dass die Auswahl der Version entscheidend ist. Wenn Sie beispielsweise com.sun.xml.ws:rt in 2.3.2 ändern, ist das Modul javax.jws nicht mehr verfügbar.

    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
        <version>2.4.0-b180830.0438</version>
    </dependency>
    <dependency>
        <groupId>com.sun.xml.ws</groupId>
        <artifactId>rt</artifactId>
        <version>2.3.1</version>
    </dependency> 

0

Ich fand, dass der einfachste Weg, um die JAXB-Teile dieser Probleme zu umgehen, darin bestand, das Abhängigkeitsmanagement in meinem Root-Pom oder in meiner Bom zu verwenden:

    <project ...>
      <dependencyManagement>
        <dependencies>
          <!-- ... -->
          <!-- Gone from jvm in java11 -->
          <dependency>
          <groupId>com.sun.xml.bind</groupId>
          <artifactId>jaxb-ri</artifactId>
          <version>2.4.0-b180830.0438</version>
          <scope>import</scope>
          <type>pom</type>
        </dependency>
        <!-- ... -->
      </dependencies>
    </dependencyManagement>
    </project>

Und in den Modulen, deren Kompilierung auf jdk11 fehlschlägt:

    <!-- ... -->
    <dependencies>
      <!-- Gone from jvm in java11 -->
      <dependency>
         <groupId>javax.xml.bind</groupId>
         <artifactId>jaxb-api</artifactId>
      </dependency>
      <dependency>
         <groupId>com.sun.xml.bind</groupId>
         <artifactId>jaxb-impl</artifactId>
         <scope>runtime</scope>
      </dependency>
      <dependency>
         <groupId>org.glassfish.jaxb</groupId>
         <artifactId>jaxb-runtime</artifactId>
         <scope>runtime</scope>
      </dependency>
      <!-- ... -->
    </dependencies>  
    <!-- ... -->

Durch das Aktualisieren der Version von org.jvnet.jaxb2.maven2:maven-jaxb2-plugin0.14.0 wurden auch alle Probleme bei der Jaxb-Generierung für mich gelöst.


Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.