web-dev-qa-db-fra.com

Remplacements de modules JPMS obsolètes avec des API Java EE

Java 9 obsolète six modules contenant des API Java EE et ils vont être supprimés prochainement

  • Java.activation avec le package javax.activation
  • Java.corba avec les packages javax.activity, javax.rmi, javax.rmi.CORBA et org.omg.*
  • Java.transaction avec le package javax.transaction
  • Java.xml.bind avec tous les packages javax.xml.bind.*
  • Java.xml.ws avec javax.jws, javax.jws.soap, javax.xml.soap et tous les packages javax.xml.ws.*
  • Java.xml.ws.annotation avec le package javax.annotation

Quels artefacts tiers maintenus fournissent ces API? Peu importe leur capacité à fournir ces API ou les autres fonctionnalités qu’ils ont à offrir. Tout ce qui compte, est-ce qu’ils remplacent immédiatement ces modules/packages?

Pour faciliter la collecte de connaissances, j'ai répondu avec ce que je savais jusqu'à présent et fait de la réponse un wiki de communauté. J'espère que les gens l'étendront au lieu d'écrire leurs propres réponses.

Avant de voter pour fermer:

  • Oui, il y a déjà quelques questions sur des modules individuels et une réponse à cette question dupliquerait bien sûr ces informations. Mais, autant que je sache, il n’ya pas de point unique pour en savoir plus sur tout cela, ce qui, à mon avis, a beaucoup de valeur.
  • Les questions demandant des recommandations de la bibliothèque sont généralement considérées comme hors sujet, car "elles ont tendance à attirer des réponses d'opinion et du spam", mais je ne pense pas que cela s'applique ici. L'ensemble des bibliothèques valides est clairement défini: elles doivent implémenter un standard spécifique. Au-delà de cela, rien d'autre ne compte, alors je ne vois pas beaucoup de risques pour l'opinion et le spam.
javajava-eejava-9java-module
101
Nicolai

Au lieu d'utiliser les modules obsolètes Java EE, utilisez les artefacts suivants.

JAF (Java.activation)

JavaBeans Activiation Framework est une technologie autonome (disponible sur Maven Central):

<dependency>
    <groupId>com.Sun.activation</groupId>
    <artifactId>javax.activation</artifactId>
    <version>1.2.0</version>
</dependency>

( La source ) 

CORBA (Java.corba)

À partir de JEP 320 :

Il n'y aura pas de version autonome de CORBA à moins que des tiers ne prennent en charge la maintenance des API CORBA, l'implémentation ORB, le fournisseur CosNaming, etc. La maintenance par des tiers est possible car la plate-forme Java SE approuve les implémentations indépendantes de CORBA. En revanche, l’API pour RMI-IIOP est définie et implémentée uniquement dans Java SE. Il n'y aura pas de version autonome de RMI-IIOP à moins qu'un JSR dédié ne soit mis à jour pour le maintenir, ou que l'intendance de l'API soit reprise par la fondation Eclipse (la transition de l'intendance de Java EE du JCP vers la fondation Eclipse inclut GlassFish et sa mise en œuvre de CORBA et RMI-IIOP).

JTA (Java.transaction)

Version autonome:

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

( Source ; Découvrez comment utiliser 1.2 et le prochain 1.3 dans le chemin de la classe et du module.)

JAXB (Java.xml.bind)

Mise en oeuvre de référence:

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

( Source ; JEP 320 explique où obtenir schemagen et xjc de.)

JAX-WS (Java.xml.ws)

Mise en oeuvre de référence:

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

( Source ; explique également où obtenir wsgen et wsimport de.)

Annotations courantes (Java.xml.ws.annotation)

Java Commons Annotations (disponible sur Maven Central):

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

( La source )

114
Nicolai

JAXB (Java.xml.bind) pour JDK9  

Fonctionne parfaitement dans mes applications de bureau sur 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

Il semble que jaxws-ri dépende transitoirement de commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852, qui peut apparemment être trouvé dans le référentiel http://download.Eclipse.org/rt/eclipselink/maven.repo

7
theNikki1

Je devais remplacer JAX-WS (Java.xml.ws) et JAXB (Java.xml.bind) pour mon application basée sur Spring Boot 2 et me suis retrouvé avec ces JAR (version 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'

(Vous aurez peut-être besoin de compile ou d'une autre portée, runtimeOnly était suffisant pour nous.)

J'ai remarqué que https://mvnrepository.com/artifact/com.Sun.xml.bind/jaxb-core est décrit comme "ancien" et que cette réponse est allé chercher des éléments basés sur org.glassfishorg.Eclipse.yasson aussi.

Maintenant, la situation est vraiment compliquée, mais ça fonctionne, mais comment peut-on s'assurer que c'est le meilleur remplaçant, non?

6
virgo47

J'ai expérimenté la plupart des suggestions décrites ci-dessus avec JDK 11.0.3 et je n'ai pas réussi. La seule solution que j'ai finalement trouvée pour fonctionner est la suivante. Il y a peut-être d'autres options qui fonctionnent aussi, mais il semble que le choix de la version est essentiel. Par exemple, si vous modifiez com.Sun.xml.ws:rt en 2.3.2, le module javax.jws n'est plus disponible.

    <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

J'ai trouvé que le moyen le plus simple de contourner les problèmes JAXB de ces problèmes était d'utiliser la gestion des dépendances dans mon pom racine ou dans mon enfant:

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

Et dans les modules qui échouent à la compilation sur 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>  
    <!-- ... -->

En outre, la mise à jour de la version de org.jvnet.jaxb2.maven2:maven-jaxb2-plugin vers la version 0.1.0 a résolu tous les problèmes de génération jaxb.

0
George

Juste une variation mineure (amélioration) des réponses ci-dessus - illustrée ici pour JAXB uniquement. On peut ajouter les dépendances avec la portée runtime et uniquement si cela est effectivement nécessaire (par exemple, lors de la construction pour une exécution dans un JRE avec la version> = 9 --- ici, la v11 est illustrée):

<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