it-swarm.com.de

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

Java 9 veraltete sechs Module, die Java EE-APIs enthalten und sie sind werden entfernt

  • Java.activation mit javax.activation-Paket
  • Java.corba mit den Paketen javax.activity, javax.rmi, javax.rmi.CORBA und org.omg.*
  • Java.transaction mit javax.transaction-Paket
  • Java.xml.bind mit allen javax.xml.bind.*-Paketen
  • Java.xml.ws mit javax.jws, javax.jws.soap, javax.xml.soap und allen javax.xml.ws.*-Paketen
  • Java.xml.ws.annotation mit javax.annotation-Paket

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

Um das Sammeln von Wissen zu erleichtern, 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 wählen, um zu schließen:

  • Ja, es gibt bereits einige Fragen zu den einzelnen Modulen, und eine Antwort auf diese Frage würde diese Informationen natürlich duplizieren. Aber bei AFAIK gibt es keinen einzigen Punkt, über den all das zu lernen ist, was meiner Meinung nach sehr wertvoll ist.
  • Fragen, die nach Bibliotheksempfehlungen fragen, werden in der Regel als unrealistisch betrachtet, da "sie dazu neigen, Meinungen und Spam einzuwerben", aber ich denke nicht, dass dies hier zutrifft. Die Menge der gültigen Bibliotheken ist klar abgegrenzt: Sie müssen einen bestimmten Standard implementieren. Darüber hinaus ist nichts anderes von Bedeutung, daher sehe ich keine Gefahr für Meinungsäußerungen und Spam.
101
Nicolai

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

JAF (Java.activation)

JavaBeans Activiation Framework ist eine Standalone-Technologie (verfügbar bei Maven Central):

<dependency>
    <groupId>com.Sun.activation</groupId>
    <artifactId>javax.activation</artifactId>
    <version>1.2.0</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-Providers usw. Die Wartung durch Dritte ist möglich, da die Java SE Platform unabhängige Implementierungen von CORBA befürwortet. Im Gegensatz dazu ist die API für RMI-IIOP ausschließlich in Java SE definiert und implementiert. Es wird keine Standalone-Version von RMI-IIOP geben, es sei denn, ein dedizierter JSR wird gestartet, um ihn zu warten, oder die API wird von der Eclipse-Stiftung übernommen. GlassFish und seine Implementierung von CORBA und RMI-IIOP).

JTA (Java.transaction)

Stand Alone Version:

<dependency>
    <groupId>javax.transaction</groupId>
    <artifactId>javax.transaction-api</artifactId>
    <version>1.2</version>
</dependency>

( Source ; sehen Sie nach, wie Sie 1.2 und den kommenden 1.3 für Klasse und Modulpfad verwenden.)

JAXB (Java.xml.bind)

Referenzimplementierung:

<!-- Java 6 = JAXB version 2.0   -->
<!-- Java 7 = JAXB version 2.2.3 -->
<!-- Java 8 = JAXB version 2.2.8 -->
<!-- Java 9 = JAXB version 2.3.0 -->
<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.2.8</version>
</dependency>
<dependency>
    <groupId>com.Sun.xml.bind</groupId>
    <artifactId>jaxb-core</artifactId>
    <version>2.2.8</version>
</dependency>
<dependency>
    <groupId>com.Sun.xml.bind</groupId>
    <artifactId>jaxb-impl</artifactId>
    <version>2.2.8</version>
</dependency>

( Quelle ; JEP 320 erläutert, woher schemagen und xjc zu erhalten sind.)

JAX-WS (Java.xml.ws)

Referenzimplementierung:

<dependency>
    <groupId>com.Sun.xml.ws</groupId>
    <artifactId>jaxws-ri</artifactId>
    <version>2.3.0</version>
    <type>pom</type>
</dependency>

( Source ; erläutert auch, woher wsgen und wsimport zu erhalten sind.)

Allgemeine Anmerkungen (Java.xml.ws.annotation)

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

<dependency>
    <groupId>javax.annotation</groupId>
    <artifactId>javax.annotation-api</artifactId>
    <version>1.3.1</version>
</dependency>

( Quelle )

114
Nicolai

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

Funktioniert perfekt in meinen Desktopanwendungen 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>
18
bourgesl

Es scheint, dass jaxws-ri transitiv von commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852 abhängt, was offensichtlich aus dem Repository http://download.Eclipse.org/rt/eclipselink/maven.repo zu finden ist

7
theNikki1

Ich musste JAX-WS (Java.xml.ws) und JAXB (Java.xml.bind) für meine auf Spring Boot 2 basierende 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 compile oder einen anderen Bereich. runtimeOnly war für uns ausreichend.)

Mir ist aufgefallen, dass https://mvnrepository.com/artifact/com.Sun.xml.bind/jaxb-core als "alt" beschrieben wird und und diese Antwort für org.glassfish-basiertes Zeug verwendet wurde org.Eclipse.yasson auch.

Jetzt ist es wirklich unordentlich, es funktioniert, aber wie sollte man sicher sein, dass es der beste Ersatz ist, richtig?

6
virgo47

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 letztendlich gefunden habe, ist die folgende. Möglicherweise funktionieren auch andere Optionen, aber die Auswahl der Version scheint entscheidend zu sein. 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
Des Albert

Ich fand den einfachsten Weg, um die JAXB-Teile dieser Probleme zu umgehen, die Abhängigkeitsverwaltung in meinem Root-Pom oder in meinem Bombe 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, die die Kompilierung auf jdk11 fehlschlagen:

    <!-- ... -->
    <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 die Aktualisierung der Version von org.jvnet.jaxb2.maven2:maven-jaxb2-plugin auf 0.14.0 wurden für mich alle Probleme mit der Jaxb-Generierung behoben.

0
George

Nur eine geringfügige Abweichung (Verbesserung) der obigen Antworten - hier nur für JAXB veranschaulicht. Sie können die Abhängigkeiten mit dem Bereich runtime hinzufügen und nur, wenn dies effektiv erforderlich ist (d. H. Wenn Sie für das Ausführen in einer JRE mit Version> = 9 --- hier wird v11 als Beispiel angegeben)

<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>
0
paul-emil