Zastąpienie przestarzałych modułów JPMS za pomocą interfejsów API Java EE


183

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.

6
Większość osób przenoszonych można znaleźć pod adresem github.com/javaee i linki do kilku szczegółów w JEP 320: Remove the Java EE and CORBA Modules
Naman

Zobacz także ten artykuł z 14.05.2018 w InfoWorld, mapa drogowa Java: Java przedsiębiorstwa Eclipse Jakarta EE została opracowana przez Paula Krilla. Podtytuł: Eclipse Foundation przedstawia 39 projektów, które składają się na nową cloud rodzimy, microservices przyjazne przedsiębiorczości wysiłku Java i jak będzie ewoluować GlassFish
Basil Bourque

2
Z JDK 11 został usunięty. Jeśli używasz jdk 9 lub nowszego, lepiej jest dodać zależność bezpośrednio, niż używając czegoś w rodzaju "--add-modules java.xml.bind"
Anver Sadhat

Odpowiedzi:


205

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 )


co zrobić w przypadku, gdy moduł czyta jax-wszarówno z jdk, jak i com.sun.xml.wszależności?
nllsdfx

1
Nie jestem pewien, o co dokładnie pytasz. Który moduł czyta jax-ws? Jeśli masz java.xml.ws na wykresie modułu i com.sun.xml.ws:jaxws-ri na ścieżce klasy, ta ostatnia zostanie zignorowana (z powodu podzielonych pakietów ).
Nicolai

Cóż, chcę używać com.sun.xml.ws:jaxws-rizamiast java.xml.wsw moim module, ponieważ ten ostatni jest przestarzały i zostanie usunięty. Dodałem zależność do mojego pliku pom i pojawił się błąd „moduł xyz odczytuje pakiet„ javax.xml.ws ”zarówno z„ java.xml.ws ”, jak i„ java.xml.ws ”.
nllsdfx

Wygląda na to, że moduł java.xml.ws został w końcu rozwiązany, być może z powodu --add-moduleslub dlatego, że wymagają tego inne moduły. Czy możesz otworzyć nowe pytanie, żebyśmy mogli się temu przyjrzeć?
Nicolai

1
To prawda. Dwa szczegóły: (1) Jeśli żaden jawny moduł (tj. Taki z deklaracją modułu) nie zależy od JAXB, nadal możesz umieścić je w ścieżce klasy, gdzie podzielone pakiety nie mają znaczenia. (2) Opcja wiersza poleceń --patch-modulemoże naprawić podział.
Nicolai

25

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>

5
Dzięki, to zadziałało dla mnie w Javie 10. Jednak użycie jednej właściwości dla numeru wersji 2.3.0dla obu jaxb-apii jaxb-runtimenie jest dobrym pomysłem. GlassFish czas pracy wynosi obecnie2.3.0.1 zaś pozostaje w API 2.3.0. Proponuję porzucić propertieselement całkowicie w odpowiedzi i po prostu zakodować na stałe każdy numer wersji w każdym z nich dependencyosobno.
Basil Bourque,

Moja rada: w <dependencyManagement>zaimportować org.glassfish.jaxb:jaxb-bomBOM w jakiejś wersji (teraz jest najnowsza 2.3.0.1), a następnie w samej <dependencies>sekcji, nie określają wersję dla albo jaxb-apialbo jaxb-runtime. Numer wersji zostanie pobrany z BOM, co zapewni ich zawsze synchronizację i wspólną aktualizację.
AndrewF

2
JAXB 2.3. [0 | 1] nie będzie już działać dla Java 11! Zobacz github.com/eclipse-ee4j/jaxb-api/issues/78
col.panic

9

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?


używamy również gradle i nigdzie nie dotarłem. Próbowałem przetłumaczyć maven solutions na gradle, ale bez powodzenia. Twój przykład działa dla mnie (chociaż użyłem kompilacji, nie dostarczono, projekt, który próbuję migrować, używa Vertx). Dzięki za udostępnienie i rzeczywiście, mam nadzieję, że wkrótce pojawią się wyjaśnienia dotyczące gradle :)
Lars

Proszę zauważyć, że sytuacja rozwija się dość szybko - niedawno przeniosłem inny projekt do Spring Boot 2.2, w którym API Jakarta są bardziej widoczne, ale nadal potrzebujemy implementacji. W tym celu nadal używam rzeczy org.glassfish. *. Za każdym razem, gdy korzystam z projektu Spring Boot, staram się sprawdzać aneks z wersjami zależności i dostosowuję się do niego w miarę możliwości (zmieniam bieżącą na wersję, której potrzebujesz): docs.spring.io/spring-boot/docs/current/reference/html/ …
virgo47

8

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


1
Prawdopodobnie dlatego, że bardziej pasował do komentarza niż odpowiedzi. Niezależnie od tego, czy byłeś w stanie rozwiązać problem? Wydaje się, że nie jestem w stanie odzyskać zależności. mvn -U clean installpowtarza Could not find artifact commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852.
Zyl

1
Nie jestem ekspertem od maven, ale wygląda na to, że znajduje commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852, gdy żadne repozytoria nie są zadeklarowane w pom.xml. Jeśli w pom.xml znajdują się repozytoria (jak spring-snapshot), należy również dodać download.eclipse.org/rt/eclipselink/maven.repository , na przykład <repository> <id> my-id </id> <name> eclipse-repo </name> <url> download.eclipse.org/rt/eclipselink/maven.repo </ url > </repository> ps.
Dodałbym

2
Mogłem go uruchomić, ale musiałem również usunąć kopię lustrzaną z mojego settings.xml. Po dalszej kontroli nie mogę jednak odtworzyć, w jaki sposób jest to zamiennik przestarzałego pakietu. Zamiast tego znalazłem tę zależność, która działa ładnie:<dependency> <groupId>javax.jws</groupId> <artifactId>jsr181-api</artifactId> <version>1.0-MR1</version> </dependency>
Zyl

Udało mi się po prostu wykluczyć pakietsdo-eclipselink-plugin
Joseph Lust,

2

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>

1

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> 

0

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.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.