Reemplazos para módulos JPMS obsoletos con API Java EE

11 minutos de lectura

Reemplazos para modulos JPMS obsoletos con API Java EE
Nicolai Parlog

Java 9 seis módulos en desuso que contienen API de Java EE y estan va a ser eliminado pronto:

  • java.activación con javax.activation paquete
  • java.corba con javax.activity, javax.rmi, javax.rmi.CORBAy org.omg.* paquetes
  • java.transacción con javax.transaction paquete
  • java.xml.bind con toda javax.xml.bind.* paquetes
  • java.xml.ws con javax.jws, javax.jws.soap, javax.xml.soapy todo javax.xml.ws.* paquetes
  • java.xml.ws.anotación con javax.annotation paquete

¿Qué artefactos de terceros mantenidos proporcionan esas API? No importa qué tan bien proporcionen esas API o qué otras funciones 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 y convertí la respuesta en 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 una respuesta a esta pregunta, por supuesto, 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 bibliotecas 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 opiniones y spam.

  • En su mayoría, puede encontrar todos los que se mudan debajo github.com/javaee y enlaces a algunos detalles en JEP 320: Eliminar los módulos Java EE y CORBA

    – Namán

    11 de enero de 2018 a las 9:59


  • Consulte también este artículo del 2018-05-14 en InfoWorld, Hoja de ruta de Java: la empresa Jakarta EE de Eclipse Java toma forma por Paul Kril. Subtítulo: La Fundación Eclipse describe los 39 proyectos que conformarán el nuevo esfuerzo Java empresarial compatible con microservicios y nativo de la nube, y cómo evolucionará GlassFish

    – Basil Bourque

    19 de julio de 2018 a las 18:31

  • De JDK 11 se ha eliminado. Si está utilizando jdk 9 o superior, es mejor agregar la dependencia directamente en lugar de usar el tipo de cosas “–add-modules java.xml.bind”

    – Anver Sadhat

    29 de octubre de 2018 a las 7:36


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

JAF (java.activación)

Marco de activación de JavaBeans (ahora Activación de Yakarta) 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)

CORBÁ (java.corba)

Desde JPY 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 que la Fundación Eclipse asuma la administración de la API (la transición de la administración de Java EE del JCP a la Fundación Eclipse incluye vidriopeces y su implementación de CORBA y RMI-IIOP).

JTA (java.transacción)

Versión independiente:

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

(Fuente)

JAXB (java.xml.bind)

Desde Java EE fue rebautizado como Jakarta EEJAXB 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>

<!-- Alternative runtime -->
<dependency>
    <groupId>org.glassfish.jaxb</groupId>
    <artifactId>jaxb-runtime</artifactId>
    <version>2.3.3</version>
    <scope>runtime</scope>
</dependency>

Página de implementación de referencia JAXB.

El tiempo de ejecución alternativo fue presentado por Abhijit Sarkar.

schemagen y xjc también se puede descargar desde allí 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 wsgen y wsimport).

Anotaciones comunes (java.xml.ws.anotación)

Anotaciones comunes de Java (disponible en Maven Central):

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

(Fuente)

  • qué hacer en caso de que un módulo lea jax-ws de jdk y com.sun.xml.ws ¿dependencia?

    – nllsdfx

    16 mayo 2018 a las 14:14

  • No estoy seguro de qué es exactamente lo que estás preguntando. ¿Qué módulo lee jax-ws? Si usted tiene java.xml.ws en el gráfico del módulo y com.sun.xml.ws:jaxws-ri en el classpath, este último será ignorado (debido a paquetes divididos).

    – Nicolai Parlog

    16 mayo 2018 a las 14:17


  • Bueno, quiero usar com.sun.xml.ws:jaxws-ri en lugar de java.xml.ws en mi módulo porque este último está en desuso y se eliminará. Y agregué la dependencia a mi archivo pom y apareció el error “el módulo xyz lee el paquete ‘javax.xml.ws’ tanto de ‘java.xml.ws’ como de ‘java.xml.ws'”.

    – nllsdfx

    16 mayo 2018 a las 14:27


  • parece el modulo java.xml.ws se resuelve después de todo, tal vez debido a una --add-modules o porque algunos otros módulos lo requieren. ¿Puedes abrir una nueva pregunta para que podamos echarle un vistazo?

    – Nicolai Parlog

    16 mayo 2018 a las 14:44

  • Eso es cierto. 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-module puede reparar la división.

    – Nicolai Parlog

    2 oct 2018 a las 21:23

1646752529 107 Reemplazos para modulos JPMS obsoletos con API Java EE
burgués

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>

  • Gracias, esto funcionó para mí en Java 10. Sin embargo, ese uso de una sola propiedad para el número de versión 2.3.0 para ambos jaxb-api y jaxb-runtime no es una buena idea los El tiempo de ejecución de Glassfish está actualmente en 2.3.0.1 mientras que la API permanece en 2.3.0. Sugiero dejar caer el properties elemento completamente en la Respuesta, y simplemente codifique cada número de versión en cada dependency por separado.

    – Basil Bourque

    17/07/2018 a las 22:40


  • Mi recomendación: en <dependencyManagement>importar el org.glassfish.jaxb:jaxb-bom BOM en alguna versión (la última ahora es 2.3.0.1), y luego en el actual <dependencies> sección, no especifique una versión para cualquiera jaxb-api o 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

    8 de noviembre de 2018 a las 3:26


  • JAXB 2.3.[0|1] ¡ya no funcionará para Java 11! Ver github.com/eclipse-ee4j/jaxb-api/issues/78

    – col.panic

    12 de diciembre de 2018 a las 9:46

Reemplazos para modulos JPMS obsoletos con API Java EE
virgo47

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 (compilació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'

(Tu puedes necesitar compile u otro alcance, runtimeOnly fue suficiente para nosotros.)

Me di cuenta que https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-core se describe como “Antiguo” y el uso de esta respuesta fue para org.glassfish cosas basadas que trajeron org.eclipse.yasson así como.

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

  • también estamos usando gradle y no llegué a ninguna parte. Intenté traducir las soluciones maven a gradle pero no tuve é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 gradle pronto 🙂

    – Lars

    20 de septiembre de 2018 a las 11:14

  • Por favor, tenga en cuenta que la situación evoluciona con bastante rapidez; recientemente, moví otro proyecto a Spring Boot 2.2, donde las API de Jakarta son más prominentes, pero también necesitamos implementaciones. Para eso sigo usando cosas de org.glassfish.*. Cada vez que uso el proyecto Spring Boot, tiendo a verificar el apéndice de sus versiones de dependencia y me ajusto a eso tanto como sea posible (cambie la versión actual a la que necesita): docs.spring.io/spring-boot/docs/current/reference/html/…

    – virgo47

    15 de junio de 2020 a las 17:56


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

Solo una variación menor (mejora) en las respuestas anteriores — ejemplificado aquí solo para JAXB. Uno puede agregar las dependencias con el runtime alcance y solo si esto es realmente necesario (es decir, cuando se compila para ejecutarse en un JRE con una 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>

Reemplazos para modulos JPMS obsoletos con API Java EE
dinithi

Si tiene el mismo problema, agregue la siguiente dependencia a pom.xml
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-rt</artifactId>
<version>2.3.3</version>
</dependency>

Luego use JAVA 8 como un JRE alternativo. Para más detalles siga https://www.youtube.com/watch?v=pgSJda16N54 video y funcionó para mí.

1646752537 356 Reemplazos para modulos JPMS obsoletos con API Java EE
de alberto

He experimentado con la mayoría de las sugerencias descritas anteriormente utilizando JDK 11.0.3 y no he tenido éxito. La única solución que finalmente encontré que funciona es la siguiente. Quizás haya otras opciones que también funcionen, 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> 

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad