Java 9 desaprobó seis módulos que contienen API Java EE y se eliminarán pronto:
- java.activation con
javax.activation
paquete - java.corba con
javax.activity
,javax.rmi
,javax.rmi.CORBA
, yorg.omg.*
paquetes - java.transaction con
javax.transaction
paquete - java.xml.bind con todos los
javax.xml.bind.*
paquetes - java.xml.ws con
javax.jws
,javax.jws.soap
,javax.xml.soap
, y todos losjavax.xml.ws.*
paquetes - java.xml.ws.annotation con
javax.annotation
paquete
¿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.
java
jakarta-ee
java-9
java-module
Nicolai
fuente
fuente
Respuestas:
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):
( Fuente )
CORBA ( java.corba )
Desde JEP 320 :
JTA ( java.transaction )
Versión independiente:
( Fuente )
JAXB ( java.xml.bind )
Dado que Java EE se cambió de nombre a Jakarta EE , JAXB ahora es proporcionado por nuevos artefactos:
Página de implementación de referencia JAXB .
schemagen
yxjc
se 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:
Descarga de distribución independiente (contiene
wsgen
ywsimport
).Anotaciones comunes ( java.xml.ws.annotation )
Anotaciones de Java Commons (disponible en Maven Central):
( Fuente )
fuente
jax-ws
tanto de jdk como decom.sun.xml.ws
dependencia?com.sun.xml.ws:jaxws-ri
lugar dejava.xml.ws
en 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'".--add-modules
o porque otros módulos lo requieren. ¿Puedes abrir una nueva pregunta para que podamos echarle un vistazo?--patch-module
puede reparar la división.JAXB (java.xml.bind) para JDK9
Funciona perfectamente en mis aplicaciones de escritorio en jdk9 / 10 EA
fuente
2.3.0
para ambosjaxb-api
yjaxb-runtime
no es una buena idea. El tiempo de ejecución de Glassfish es actualmente2.3.0.1
mientras que la API permanece en2.3.0
. Sugiero colocar elproperties
elemento por completo en la respuesta, y simplemente codificar cada número de versión en cada uno pordependency
separado.<dependencyManagement>
, importe laorg.glassfish.jaxb:jaxb-bom
lista 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 ningunojaxb-api
ojaxb-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.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):
(Es posible que necesite
compile
u otro alcance,runtimeOnly
fue 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.glassfish
cosas basadas que también se incorporaronorg.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?
fuente
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
fuente
mvn -U clean install
sigue diciendoCould not find artifact commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852
.<dependency> <groupId>javax.jws</groupId> <artifactId>jsr181-api</artifactId> <version>1.0-MR1</version> </dependency>
sdo-eclipselink-plugin
Solo una pequeña variación (mejora) en las respuestas anteriores --- ejemplificada aquí solo para JAXB. Se pueden 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 versión> = 9 --- aquí se ejemplifica v11):fuente
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.
fuente
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:
Y en los módulos que fallan la compilación en jdk11:
Además, la actualización de la versión de
org.jvnet.jaxb2.maven2:maven-jaxb2-plugin
0.14.0 resolvió todos los problemas de generación de jaxb para mí.fuente
Estoy usando jdk 11 + ant + ivy en mi proyecto mvc de primavera. Recibí el error "el paquete javax.jws no existe ", así que agregué javax.jws-api-1.1.jar a classpath y funcionó. Simplemente descargue el jar desde https://repo1.maven.org/maven2/javax/jws/javax.jws-api/1.1/javax.jws-api-1.1.jar y agréguelo a su classpath en su build.xml
fuente