Reemplazos para módulos JPMS en desuso con API Java EE

183

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

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

¿Qué artefactos de terceros mantenidos proporcionan esas API? No importa qué tan bien proporcionen esas API o qué otras características tengan para ofrecer. Lo único que importa es si son un reemplazo directo para estos módulos / paquetes.

Para facilitar la recopilación de conocimientos, respondí con lo que sé hasta ahora e hice la respuesta un wiki de la comunidad. Espero que la gente lo extienda 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 punto único para aprender sobre todo esto, lo que creo que tiene mucho valor.
  • Las preguntas que solicitan recomendaciones de la biblioteca generalmente se consideran fuera de tema, porque "tienden a atraer respuestas obstinadas y spam", 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, así que no veo mucho riesgo de opinión y spam.
Nicolai
fuente
66
En su mayoría puede encontrar todos los que se mueven en github.com/javaee y enlaces a algunos detalles en JEP 320: Elimine los módulos Java EE y CORBA
Naman
Consulte también este artículo del 2018-05-14 en InfoWorld, hoja de ruta de Java: Eclipse Jakarta EE Enterprise Java toma forma por Paul Krill. Subtítulo: La Fundación Eclipse describe los 39 proyectos que conformarán el nuevo esfuerzo Java empresarial nativo de la nube y compatible con los microservicios, y cómo evolucionará GlassFish
Basil Bourque
2
De JDK 11 se ha eliminado. Si está utilizando jdk 9 o superior, es mejor agregar la dependencia directamente en lugar de utilizar el tipo de cosas "--add-modules java.xml.bind"
Anver Sadhat

Respuestas:

205

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

JAF ( java.activation )

JavaBeans Activation Framework (ahora Jakarta Activation ) es una tecnología independiente (disponible en Maven Central):

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

( Fuente )

CORBA ( java.corba )

Desde JEP 320 :

No habrá una versión independiente de CORBA a menos que terceros se hagan cargo 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 implementaciones independientes de CORBA. Por el contrario, la API para RMI-IIOP se define e implementa únicamente dentro de Java SE. No habrá una versión independiente de RMI-IIOP a menos que se inicie un JSR dedicado para mantenerlo, o la administración de la API sea asumida por 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 independiente:

<dependency>
    <groupId>jakarta.transaction</groupId>
    <artifactId>jakarta.transaction-api</artifactId>
    <version>1.3.3</version>
</dependency>

( Fuente )

JAXB ( java.xml.bind )

Dado que Java EE se cambió de nombre a Jakarta EE , JAXB ahora es proporcionado por nuevos artefactos:

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

Página de implementación de referencia JAXB .

schemageny xjcse puede descargar allí también como parte de una distribución JAXB independiente.

Ver también la respuesta vinculada .

JAX-WS ( java.xml.ws )

Implementación de referencia:

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

Descarga de distribución independiente (contiene wsgeny wsimport).

Anotaciones comunes ( java.xml.ws.annotation )

Anotaciones de Java Commons (disponible en Maven Central):

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

( Fuente )

Nicolai
fuente
¿Qué hacer en caso de que un módulo lea jax-wstanto de jdk como de com.sun.xml.wsdependencia?
nllsdfx
1
No estoy seguro de qué estás preguntando exactamente. ¿Qué módulo lee jax-ws? Si tiene java.xml.ws en el gráfico del módulo y com.sun.xml.ws:jaxws-ri en la ruta de clase, este último será ignorado (debido a los paquetes divididos ).
Nicolai
Bueno, quiero usar en com.sun.xml.ws:jaxws-rilugar de java.xml.wsen mi módulo porque este último está en desuso y será eliminado. Y agregué la dependencia a mi archivo pom y apareció el error "módulo xyz lee el paquete 'javax.xml.ws' de 'java.xml.ws' y 'java.xml.ws'".
nllsdfx
Parece que el módulo java.xml.ws está resuelto después de todo, tal vez debido a un --add-moduleso porque otros módulos lo requieren. ¿Puedes abrir una nueva pregunta para que podamos echarle un vistazo?
Nicolai
1
Es verdad. Dos detalles: (1) Si ningún módulo explícito (es decir, uno con una declaración de módulo) depende de JAXB, aún puede colocarlos en la ruta de clase, donde los paquetes divididos no importan. (2) La opción de línea de comando --patch-modulepuede reparar la división.
Nicolai
25

JAXB (java.xml.bind) para JDK9

Funciona perfectamente en mis aplicaciones de escritorio en 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>
burguesa
fuente
55
Gracias, esto funcionó para mí en Java 10. Sin embargo, el uso de una sola propiedad para el número de versión 2.3.0para ambos jaxb-apiy jaxb-runtimeno es una buena idea. El tiempo de ejecución de Glassfish es actualmente2.3.0.1 mientras que la API permanece en 2.3.0. Sugiero colocar el propertieselemento por completo en la respuesta, y simplemente codificar cada número de versión en cada uno por dependencyseparado.
Basil Bourque
Mi recomendación: en <dependencyManagement>, importe la org.glassfish.jaxb:jaxb-bomlista de materiales en alguna versión (la última ahora es 2.3.0.1), y luego, en la <dependencies>sección real , no especifique una versión para ninguno jaxb-apio jaxb-runtime. El número de versión se tomará de la lista de materiales, lo que garantizará que siempre estén sincronizados y se actualicen juntos.
AndrewF
2
¡JAXB 2.3. [0 | 1] ya no funcionará para Java 11! Ver github.com/eclipse-ee4j/jaxb-api/issues/78
col.panic
9

Necesitaba reemplazar JAX-WS (java.xml.ws) y JAXB (java.xml.bind) para mi aplicación basada en Spring Boot 2 y terminé con estos JAR (construcción de 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'

(Es posible que necesite compileu otro alcance, runtimeOnlyfue suficiente para nosotros).

Noté que https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-core se describe como "Viejo" y el uso de esta respuesta fue para org.glassfishcosas basadas que también se incorporaron org.eclipse.yasson.

Ahora es una situación realmente desordenada, funciona, pero ¿cómo debería alguien estar seguro de que es el mejor reemplazo, verdad?

virgo47
fuente
También estamos usando Gradle y no llegué a ninguna parte. Intenté traducir las soluciones de Maven a gradle pero no tuvimos éxito. Su ejemplo funciona para mí (aunque se usa la compilación, no se proporciona, el proyecto que intento migrar está usando vertx). Gracias por compartir y de hecho, también espero que haya algunas aclaraciones sobre el gradle pronto :)
Lars
Tenga en cuenta que la situación evoluciona bastante rápido: hace poco, trasladé otro proyecto a Spring Boot 2.2, donde las API de Yakarta son más prominentes, pero también necesitamos implementaciones. Para eso todavía uso org.glassfish. * Stuff. Cada vez que uso el proyecto Spring Boot, tiendo a verificar el apéndice de sus versiones de dependencia y cumplir con eso tanto como sea posible (cambie la versión actual a la que necesita): docs.spring.io/spring-boot/docs/current/reference/html/ ...
virgo47
8

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

theNikki1
fuente
1
Probablemente porque era más adecuado para un comentario que para una respuesta. En cualquier caso, ¿pudo solucionar el problema? Parece que no puedo recuperar la dependencia. mvn -U clean installsigue diciendo Could not find artifact commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852.
Zyl
1
No soy un experto en Maven, pero parece que está encontrando commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852 cuando no se declaran repositorios en pom.xml. Si hay repositorios en pom.xml (como spring-snapshot) también se debe agregar download.eclipse.org/rt/eclipselink/maven.repository , por ejemplo <repository> <id> my-id </id> <name> eclipse-repo </name> <url> download.eclipse.org/rt/eclipselink/maven.repo </ url > </repository> ps. Hubiera agregado un comentario en lugar de una respuesta si mi reputación fuera lo suficientemente grande :)
theNikki1
2
Pude hacerlo funcionar, pero también tuve que eliminar un espejo de mi settings.xml. Sin embargo, después de una inspección adicional, no puedo reproducir cómo esto es un reemplazo para el paquete obsoleto. En cambio, encontré esta dependencia que funciona muy bien:<dependency> <groupId>javax.jws</groupId> <artifactId>jsr181-api</artifactId> <version>1.0-MR1</version> </dependency>
Zyl
Pude simplemente excluir el paquetesdo-eclipselink-plugin
Joseph Lust
2

Solo una pequeña variación (mejora) en las respuestas anteriores --- ejemplificada aquí solo para JAXB. Se pueden agregar las dependencias con el runtimealcance y solo si esto es realmente necesario (es decir, cuando se compila para ejecutarse en un JRE con versión> = 9 --- aquí se ejemplifica 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>
paul-emil
fuente
1

He experimentado con la mayoría de las sugerencias descritas anteriormente usando JDK 11.0.3 y no he tenido éxito. La única solución que finalmente encontré que funciona es la siguiente. Quizás hay otras opciones que también funcionan, pero parece que la selección de la versión es crítica. Por ejemplo, cambiar com.sun.xml.ws:rt a 2.3.2 hace que el módulo javax.jws ya no esté 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
fuente
0

Encontré que el camino más fácil para sortear las partes JAXB de estos problemas era usar la administración de dependencias en mi root pom o en mi bom:

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

Y en los módulos que fallan la compilación en 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>  
    <!-- ... -->

Además, la actualización de la versión de org.jvnet.jaxb2.maven2:maven-jaxb2-plugin0.14.0 resolvió todos los problemas de generación de jaxb para mí.

Jorge
fuente