Reemplazos para módulos JPMS obsoletos con API de Java EE

Java 9 desaprobó seis módulos que contienen API de Java EE y se eliminarán pronto:

  • java.activation con el paquete javax.activation
  • java.corba con los javax.activity , javax.rmi , javax.rmi.CORBA y org.omg.*
  • java.transaction con el paquete javax.transaction
  • java.xml.bind con todos los paquetes javax.xml.bind.*
  • java.xml.ws con javax.jws , javax.jws.soap , javax.xml.soap y todos los paquetes javax.xml.ws.*
  • java.xml.ws.annotation con el paquete javax.annotation

¿Qué artefactos de terceros mantenidos proporcionan esas API? No importa qué tan bien proporcionen esas API o qué otras características tienen para ofrecer; todo lo que importa es, ¿son un reemplazo directo para estos módulos / paquetes?

Para que sea más fácil recostackr knoweldge, respondí con lo que sé hasta ahora y convertí la respuesta en una wiki comunitaria. Espero que las personas lo extiendan en lugar de escribir sus propias respuestas.


Antes de votar para cerrar:

  • Sí, ya hay algunas preguntas sobre módulos individuales y, por supuesto, una respuesta a esta pregunta duplicaría esa información. Pero AFAIK no hay un solo punto para aprender sobre todos estos, que creo que tiene mucho valor.
  • Las preguntas que piden recomendaciones de la biblioteca generalmente se consideran fuera de tema, porque “tienden a atraer respuestas obstinadas y correo no deseado”, pero no creo que eso se aplique aquí. El conjunto de bibliotecas válidas está claramente delineado: tienen que implementar un estándar específico. Más allá de eso, nada más importa, por lo que no veo mucho riesgo de opinión y spam.

En lugar de utilizar los módulos Java EE en desuso, use los siguientes artefactos.

JAF ( java.activation )

JavaBeans Activiation Framework es una tecnología independiente (disponible en Maven Central):

  com.sun.activation javax.activation 1.2.0  

( Fuente )

CORBA ( java.corba )

De JEP 320 :

No habrá una versión independiente de CORBA a menos que terceros se encarguen del mantenimiento de las API de CORBA, la implementación de ORB, el proveedor de CosNaming, etc. El mantenimiento de terceros es posible porque la plataforma Java SE respalda las implementaciones independientes de CORBA. Por el contrario, la API para RMI-IIOP se define e implementa únicamente en Java SE. No habrá una versión independiente de RMI-IIOP a menos que se inicie un JSR dedicado para mantenerla, o la administración de la API se haga cargo de la Fundación Eclipse (la transición de la administración de Java EE del JCP a la Fundación Eclipse incluye GlassFish y su implementación de CORBA y RMI-IIOP).

JTA ( java.transaction )

Versión autónoma:

  javax.transaction javax.transaction-api 1.2  

( Fuente , eche un vistazo a cómo usar 1.2 y el próximo 1.3 en la clase y la ruta del módulo).

JAXB ( java.xml.bind )

Implementación de referencia:

      javax.xml.bind jaxb-api 2.2.8   com.sun.xml.bind jaxb-core 2.2.8   com.sun.xml.bind jaxb-impl 2.2.8  

( Fuente ; JEP 320 explica de dónde obtener schemagen y schemagen ).

JAX-WS ( java.xml.ws )

Implementación de referencia:

  com.sun.xml.ws jaxws-ri 2.3.0 pom  

( Fuente : también explica de dónde obtener wsgen y wsimport ).

Anotaciones comunes ( java.xml.ws.annotation )

Anotaciones de Java Commons (disponible en Maven Central):

  javax.annotation javax.annotation-api 1.3.1  

( Fuente )

JAXB (java.xml.bind) para JDK9

Trabajando perfectamente en mis aplicaciones de escritorio en jdk9 / 10 EA

  2.3.0    javax.xml.bind jaxb-api ${jaxb-api.version}   org.glassfish.jaxb jaxb-runtime ${jaxb-api.version}    javax.activation javax.activation-api 1.2.0  

Parece que jaxws-ri depende transitivamente de commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852 que aparentemente se puede encontrar en el repository http://download.eclipse.org/rt/eclipselink/maven.repo