Remplacement des modules JPMS obsolètes par des API Java EE

183

Java 9 a déprécié six modules contenant des API Java EE et ils seront bientôt supprimés :

  • java.activation avec javax.activationpackage
  • java.corba avec javax.activity, javax.rmi, javax.rmi.CORBAet org.omg.*paquets
  • java.transaction avec javax.transactionpackage
  • java.xml.bind avec tous les javax.xml.bind.*packages
  • java.xml.ws avec javax.jws, javax.jws.soap, javax.xml.soapet tous les javax.xml.ws.*paquets
  • java.xml.ws.annotation avec javax.annotationpackage

Quels artefacts tiers maintenus fournissent ces API? Peu importe la qualité de ces API ou les autres fonctionnalités qu'elles ont à offrir - tout ce qui compte, c'est qu'ils remplacent ces modules / packages?

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


Avant de voter pour fermer:

  • Oui, il y a déjà des questions sur les modules individuels et une réponse à cette question dupliquerait bien sûr cette information. Mais AFAIK, il n'y a 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élimité: elles doivent implémenter une norme spécifique. Au-delà de cela, rien d'autre n'a d'importance, donc je ne vois pas beaucoup de risque d'opinion et de spam.
Nicolai
la source
6
Vous pouvez principalement trouver tous ceux qui ont été déplacés sous github.com/javaee et des liens vers quelques détails sur JEP 320: Supprimez les modules Java EE et CORBA
Naman
Voir aussi cet article du 14/05/2018 dans InfoWorld, feuille de route Java: l'entreprise Java Jakarta EE d'Eclipse prend forme par Paul Krill. Sous-titre: La Fondation Eclipse décrit les 39 projets qui constitueront le nouvel effort Java d'entreprise cloud natif et compatible avec les microservices, et comment GlassFish va évoluer
Basil Bourque
2
À partir du JDK 11, il a été supprimé. Si vous utilisez jdk 9 ou supérieur, il est préférable d'ajouter la dépendance directement plutôt que d'utiliser le genre de trucs "--add-modules java.xml.bind"
Anver Sadhat

Réponses:

205

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

JAF ( java.activation )

JavaBeans Activation Framework (maintenant Jakarta Activation ) est une technologie autonome (disponible sur Maven Central):

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

( 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. 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 lancé pour le maintenir, ou que la gestion de l'API soit prise en charge par la Fondation Eclipse (la transition de la gestion 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>jakarta.transaction</groupId>
    <artifactId>jakarta.transaction-api</artifactId>
    <version>1.3.3</version>
</dependency>

( Source )

JAXB ( java.xml.bind )

Depuis que Java EE a été renommé Jakarta EE , JAXB est désormais fourni par de nouveaux artefacts:

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

Page d'implémentation de référence JAXB .

schemagenet xjcpeut être téléchargé là aussi dans le cadre d'une distribution JAXB autonome.

Voir également la réponse liée .

JAX-WS ( java.xml.ws )

Implémentation de référence:

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

Téléchargement de la distribution autonome (contient wsgenet wsimport).

Annotations courantes ( java.xml.ws.annotation )

Annotations Java Commons (disponibles sur Maven Central):

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

( Source )

Nicolai
la source
que faire au cas où un module lit jax-wsà la fois jdk et com.sun.xml.wsdépendances?
nllsdfx
1
Je ne sais pas exactement ce que vous demandez. Quel module lit jax-ws? Si vous avez java.xml.ws dans le graphe du module et com.sun.xml.ws:jaxws-ri sur le chemin de classe, ce dernier sera ignoré (à cause des packages fractionnés ).
Nicolai
Eh bien, je veux utiliser à la com.sun.xml.ws:jaxws-riplace de java.xml.wsdans mon module car ce dernier est obsolète et sera supprimé. Et j'ai ajouté la dépendance à mon fichier pom et l'erreur "module xyz lit le package 'javax.xml.ws' à la fois dans 'java.xml.ws' et 'java.xml.ws'" est apparue.
nllsdfx
Il semble que le module java.xml.ws soit résolu après tout, peut-être à cause d'un --add-modulesou parce que d'autres modules le nécessitent. Pouvez-vous ouvrir une nouvelle question pour que nous puissions l'examiner?
Nicolai
1
C'est vrai. Deux détails: (1) Si aucun module explicite (c.-à-d. Un avec une déclaration de module) ne dépend de JAXB, vous pouvez toujours les placer sur le chemin de classe, où les paquets fractionnés n'ont pas d'importance. (2) L'option de ligne de commande --patch-modulepeut réparer le fractionnement.
Nicolai
25

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>
Bourgesl
la source
5
Merci, cela a fonctionné pour moi sur Java 10. Cependant, cette utilisation d'une seule propriété pour le numéro de version 2.3.0pour les deux jaxb-apiet jaxb-runtimen'est pas une bonne idée. Le runtime Glassfish est actuellement à2.3.0.1 tandis que l'API reste à 2.3.0. Je suggère de supprimer propertiesentièrement l' élément dans la réponse et de coder en dur chaque numéro de version dependencyséparément.
Basil Bourque
Ma recommandation: dans <dependencyManagement>, importez la org.glassfish.jaxb:jaxb-bomnomenclature dans une version (la dernière version est maintenant 2.3.0.1), puis dans la <dependencies>section réelle , ne spécifiez pas de version pour jaxb-apiou jaxb-runtime. Le numéro de version sera extrait de la nomenclature, ce qui garantira qu'ils sont toujours synchronisés et mis à niveau ensemble.
AndrewF
2
JAXB 2.3. [0 | 1] ne fonctionnera plus pour Java 11! Voir github.com/eclipse-ee4j/jaxb-api/issues/78
col.panic
9

J'avais besoin de remplacer JAX-WS (java.xml.ws) et JAXB (java.xml.bind) pour mon application basée sur Spring Boot 2 et j'ai fini 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 pourriez avoir besoin d' compileune autre portée, runtimeOnlyc'était suffisant pour nous.)

J'ai remarqué que https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-core est décrit comme "Old" et que l'utilisation de cette réponse est allée pour des org.glassfishéléments basés qui ont également apporté org.eclipse.yasson.

Maintenant, c'est une situation vraiment compliquée, cela fonctionne, mais comment devrait-on être sûr que c'est le meilleur remplacement, non?

virgo47
la source
nous utilisons également gradle et je ne suis allé nulle part. J'ai essayé de traduire les solutions maven pour graduer mais sans succès. Votre exemple fonctionne pour moi (utilisé pour la compilation, non fourni, le projet que j'essaie de migrer utilise vertx). Merci pour le partage et j'espère aussi qu'il y aura bientôt des clarifications concernant gradle :)
Lars
Veuillez noter que la situation évolue assez rapidement - tout récemment, j'ai déplacé un autre projet vers Spring Boot 2.2 où les API Jakarta sont plus importantes, mais nous avons également encore besoin d'implémentations. Pour cela, j'utilise encore des trucs org.glassfish. *. Chaque fois que j'utilise le projet Spring Boot, j'ai tendance à vérifier l'annexe des versions de dépendance et à me conformer à cela autant que possible (changez la version actuelle à la version dont vous avez besoin): docs.spring.io/spring-boot/docs/current/reference/html/ …
virgo47
8

Il semble que jaxws-ri dépend de manière transitoire de commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852 qui peut apparemment être trouvé à partir du référentiel http://download.eclipse.org/rt/eclipselink/maven.repo

theNikki1
la source
1
Probablement parce qu'il était plus adapté à un commentaire qu'à une réponse. Quoi qu'il en soit, avez-vous pu résoudre le problème? Je ne semble pas être en mesure de récupérer la dépendance. mvn -U clean installrépète Could not find artifact commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852.
Zyl
1
Je ne suis pas un expert en maven, mais il semble qu'il trouve commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852 quand aucun dépôt n'est déclaré dans pom.xml. S'il y a des référentiels dans pom.xml (comme spring-snapshot), il faut également ajouter download.eclipse.org/rt/eclipselink/maven.repository , par exemple <repository> <id> my-id </id> <name> eclipse-repo </name> <url> download.eclipse.org/rt/eclipselink/maven.repo </ url > </repository> ps. J'aurais ajouté un commentaire au lieu de répondre si ma réputation était assez grande :)
theNikki1
2
Je pouvais le faire fonctionner, mais je devais également supprimer un miroir de mon settings.xml. Cependant, après une inspection plus approfondie, je ne peux pas reproduire en quoi il s'agit d'un remplacement du package obsolète. Au lieu de cela, j'ai trouvé cette dépendance qui fonctionne bien:<dependency> <groupId>javax.jws</groupId> <artifactId>jsr181-api</artifactId> <version>1.0-MR1</version> </dependency>
Zyl
J'ai pu simplement exclure le packagesdo-eclipselink-plugin
Joseph Lust
2

Juste une variation mineure (amélioration) sur les réponses ci-dessus --- illustrée ici pour JAXB uniquement. On peut ajouter les dépendances avec la runtimeportée et seulement si cela est effectivement nécessaire (c'est-à-dire lors de la construction pour s'exécuter dans un JRE avec 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>
paul-emil
la source
1

J'ai expérimenté la plupart des suggestions décrites ci-dessus en utilisant 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 existe peut-être d'autres options qui fonctionnent également, mais il semble que le choix de la version soit critique. Par exemple, changer com.sun.xml.ws:rt en 2.3.2 fait que 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> 
Des Albert
la source
0

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

    <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 la version org.jvnet.jaxb2.maven2:maven-jaxb2-pluginà 0.14.0 a résolu tous les problèmes de génération de JAXB pour moi.

George
la source
0

J'utilise jdk 11 + fourmi + lierre dans mon projet printemps mvc. J'obtenais l' erreur " package javax.jws n'existe pas " alors j'ai ajouté javax.jws-api-1.1.jar au classpath et cela a fonctionné! Téléchargez simplement le fichier jar depuis https://repo1.maven.org/maven2/javax/jws/javax.jws-api/1.1/javax.jws-api-1.1.jar Et ajoutez-le à votre classpath dans votre build.xml

Shiva
la source