Remplacements de modules JPMS dépréciés par des API Java EE

Question

Java 9 obsolète six modules qui contiennent des Api Java EE et qu'ils sont va être retiré dès:

• java.activation avec javax.activation package
• java.corba avec javax.activity, javax.rmi, javax.rmi.CORBA, et org.omg.* forfaits
• java.transaction avec javax.transaction package
• java.xml.lier avec tous javax.xml.bind.* forfaits
• java.xml.ws avec javax.jws, javax.jws.soap, javax.xml.soap, et tous javax.xml.ws.* forfaits
• java.xml.ws.annotation avec javax.annotation package

Qui a maintenu tiers des artefacts de fournir les Api? Il n'a pas d'importance comment ils fournir les Api ou d'autres fonctions qu'ils ont à offrir, tout ce qui compte est, sont-ils une baisse-dans le remplacement de ces modules/packages?

Pour le rendre plus facile de recueillir des informations, j'ai répondu avec ce que je sais jusqu'à présent et a fait la réponse d'un wiki de la communauté. J'espère que les gens vont l'étendre au lieu d'écrire leurs propres réponses.

---

Avant de voter pour fermer:

• Oui, il y a déjà quelques questions sur les différents modules et une réponse à cette question serait, bien entendu, de duplication de l'information. Mais autant que je sache, il n'y a pas un seul point d'apprendre à propos de tous ces, qui, je pense, a beaucoup de valeur.
• Questions demandant bibliothèque recommandations sont généralement considérés comme étant hors-sujet, car "ils ont tendance à attirer les opinions des réponses et des spam", mais je ne pense pas que cela s'applique ici. La validité des bibliothèques est clairement définie: Ils ont à mettre en œuvre une norme spécifique. Au-delà de que rien d'autre ne compte, donc je ne vois pas beaucoup de risque pour avis et le spam.

Answer 1

Au lieu d'utiliser le obsolète Java EE des modules, utiliser les objets suivants.

JAF (java.activation)

JavaBeans Activiation Cadre autonome de la technologie (disponible sur Maven Central):

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

(Source)

CORBA (java.corba)

De JEP 320:

Il n'y aura pas une version autonome de CORBA, sauf si des tiers au cours de l'entretien de l'Api CORBA, ORBE de mise en œuvre, CosNaming fournisseur, etc. Troisième partie de l'entretien est possible parce que le Java SE Platform approuve implémentations indépendantes de CORBA. En revanche, l'API RMI-IIOP est défini et mis en œuvre uniquement à l'intérieur de Java SE. Il n'y aura pas une version autonome de RMI-IIOP, à moins qu'un dédié JSR est commencé à le maintenir, d'intendance ou de l'API est pris en charge par la Fondation Eclipse (la transition de l'intendance de Java EE depuis le PLAN de la Fondation Eclipse comprend GlassFish et son implémentation de CORBA et RMI-IIOP).

JTA (java.la transaction)

Version autonome:

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

(Source; prendre un coup d'oeil pour savoir comment utiliser 1.2 et du prochain 1.3 sur la classe et le chemin d'accès du module.)

JAXB (java.xml.bind)

L'implémentation 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ù trouver de l' schemagen et xjc à partir de).

JAX-WS (java.xml.ws)

L'implémentation 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 aussi où obtenir de l' wsgen et wsimport à partir de).

Commune d'Annotations (java.xml.ws.annotation)

Java Communes Annotations (disponible sur Maven Central):

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

(Source)

Answer 2

JAXB (java.xml.bind) pour JDK9

Travailler parfaitement dans mes applications de bureau sur jdk9/10 EA

Answer 3

J'avais besoin de remplacer JAX-WS (java.xml.ws) et JAXB (java.xml.bind) pour mon Ressort de Démarrage 2 en fonction de l'application et a terminé avec ces Pots (build 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 pouvez avoir besoin d' compile ou 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 "Vieux" et à l'aide de cette réponse est allé pour org.glassfish basée sur des trucs qui amena org.eclipse.yasson ainsi.

Maintenant, il est vraiment situation délicate, il fonctionne, mais comment doit-on être sûr que c'est le meilleur remplacement, droit?

Answer 4

Il semble que jaxws-ri dépend transitoirement de commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852 qui apparemment peut être trouvé à partir du dépôt http://download.eclipse.org/rt/eclipselink/maven.repo

Answer 5

Juste une variation mineure (amélioration) sur les réponses ci-dessus --- illustré ici pour JAXB seulement. On peut ajouter les dépendances avec la portée et seulement si cela est effectivement nécessaire (c'est-à-dire lors de la construction pour l'exécution dans un JRE avec la `` version 'gt;9 ici --- ici v11 est illustré):