Java 9 wycofała sześć modułów zawierających interfejsy API Java EE i wkrótce zostaną one usunięte :

• java.activation z javax.activationpakietem
• java.corba z javax.activity, javax.rmi, javax.rmi.CORBAi org.omg.*pakiety
• java.transaction with javax.transactionpackage
• java.xml.bind ze wszystkimi javax.xml.bind.*pakietami
• java.xml.ws z javax.jws, javax.jws.soap, javax.xml.soapi wszystkich javax.xml.ws.*pakietów
• java.xml.ws.annotation z javax.annotationpakietem

Które utrzymywane artefakty innych firm zapewniają te interfejsy API? Nie ma znaczenia, jak dobrze zapewniają te interfejsy API lub jakie inne funkcje mają do zaoferowania - wszystko, co się liczy, to czy są one zamiennikami tych modułów / pakietów?

Aby ułatwić gromadzenie wiedzy, odpowiedziałem, podając to, co wiem do tej pory, i uczyniłem odpowiedź wiki społeczności. Mam nadzieję, że ludzie będą go przedłużać, zamiast pisać własne odpowiedzi.

Zanim zagłosujesz za zamknięciem:

• Tak, jest już kilka pytań dotyczących poszczególnych modułów, a odpowiedź na to pytanie oczywiście powieliłaby te informacje. Ale AFAIK, nie ma sensu uczyć się o tym wszystkim, co moim zdaniem ma dużą wartość.
• Pytania z prośbą o rekomendacje biblioteczne są zwykle uważane za niezwiązane z tematem, ponieważ „zwykle przyciągają uparte odpowiedzi i spam”, ale nie sądzę, żeby to miało tutaj zastosowanie. Zestaw ważnych bibliotek jest jasno określony: muszą wdrażać określony standard. Poza tym nic innego się nie liczy, więc nie widzę dużego ryzyka dla opinii i spamu.

Zamiast używać przestarzałych modułów Java EE, użyj następujących artefaktów.

JAF ( java.activation )

JavaBeans Activation Framework (obecnie Jakarta Activation ) to samodzielna technologia (dostępna w Maven Central):

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

( Źródło )

CORBA ( java.corba )

Od JEP 320 :

Nie będzie samodzielnej wersji CORBA, chyba że strony trzecie przejmą opiekę nad API CORBA, implementacją ORB, dostawcą CosNaming itp. Konserwacja strony trzeciej jest możliwa, ponieważ platforma Java SE wspiera niezależne implementacje CORBA. Natomiast API dla RMI-IIOP jest zdefiniowane i zaimplementowane wyłącznie w Javie SE. Nie będzie samodzielnej wersji RMI-IIOP, chyba że dedykowany JSR zacznie ją utrzymywać lub zarządzanie API przejmie Eclipse Foundation (przejście zarządzania Java EE z JCP do Eclipse Foundation obejmuje GlassFish i jego implementacja CORBA i RMI-IIOP).

JTA ( java.transaction )

Wersja samodzielna:

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

( Źródło )

JAXB ( java.xml.bind )

Od czasu zmiany nazwy Java EE na Jakarta EE , JAXB jest teraz dostarczany przez nowe artefakty:

<!-- 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>

Strona implementacji referencji JAXB .

schemageni xjcmożna je tam również pobrać jako część samodzielnej dystrybucji JAXB.

Zobacz także połączoną odpowiedź .

JAX-WS ( java.xml.ws )

Realizacja referencyjna:

<!-- 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>

Samodzielne pobieranie dystrybucji (zawiera wsgeni wsimport).

Typowe adnotacje ( java.xml.ws.annotation )

Java Commons Adnotations (dostępne w Maven Central):

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

( Źródło )

JAXB (java.xml.bind) dla JDK9

Działa idealnie w moich aplikacjach desktopowych na 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>

Musiałem wymienić JAX-WS (java.xml.ws) i JAXB (java.xml.bind) na moją aplikację opartą na Spring Boot 2 i skończyło się na tych JAR (kompilacja Gradle):

// 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'

(Możesz potrzebować compilelub inny zakres, runtimeOnlywystarczył nam.)

Zauważyłem, że https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-core jest opisany jako „stary” i stosując tę odpowiedź udał się do org.glassfishrzeczy, które przyniósł w oparciu org.eclipse.yassonrównież.

Teraz sytuacja jest naprawdę nieporządna, działa, ale jak ktoś powinien mieć pewność, że to najlepszy zamiennik, prawda?

Wygląda na to, że jaxws-ri zależy przejściowo od commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852, które najwyraźniej można znaleźć w repozytorium http://download.eclipse.org/rt/eclipselink/maven.repo

Tylko niewielka zmiana (poprawa) w powyższych odpowiedziach --- zilustrowana tutaj tylko dla JAXB. Można dodać zależności z runtimezakresem i tylko wtedy, gdy jest to efektywnie potrzebne (np. Podczas budowania do pracy w środowisku JRE z wersją> = 9 - tutaj przykład v11):

<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>

Eksperymentowałem z większością opisanych powyżej sugestii przy użyciu JDK 11.0.3 i nie odniosłem sukcesu. Jedyne rozwiązanie, które ostatecznie zadziałało, jest następujące. Być może istnieją inne opcje, które również działają, ale wydaje się, że wybór wersji jest krytyczny. Na przykład zmiana com.sun.xml.ws:rt na 2.3.2 spowoduje, że moduł javax.jws przestanie być dostępny.

    <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> 

Odkryłem, że najłatwiejszą drogą do obejścia części JAXB tych problemów jest użycie zarządzania zależnościami w moim głównym pomie lub w moim urodzeniu:

    <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>

A w modułach, które nie kompilują się na jdk11:

    <!-- ... -->
    <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>  
    <!-- ... -->

Ponadto aktualizacja do wersji org.jvnet.jaxb2.maven2:maven-jaxb2-plugin0.14.0 rozwiązała wszystkie problemy z generowaniem jaxb.

Używam jdk 11 + ant + ivy w moim wiosennym projekcie MVC. Pojawiał się błąd „ pakiet javax.jws nie istnieje ”, więc dodałem javax.jws-api-1.1.jar do ścieżki klasy i zadziałało! Po prostu pobierz jar z https://repo1.maven.org/maven2/javax/jws/javax.jws-api/1.1/javax.jws-api-1.1.jar i dodaj go do swojej ścieżki klas w pliku build.xml