Substituições para módulos JPMS reprovados com APIs do Java EE

O Java 9 preteriu seis módulos que contêm APIs do Java EE e eles serão removidos em breve:

  • java.activation com o pacote javax.activation
  • java.corba com pacotes javax.activity , javax.rmi , javax.rmi.CORBA e org.omg.*
  • java.transaction com o pacote javax.transaction
  • java.xml.bind com todos os pacotes javax.xml.bind.*
  • java.xml.ws com javax.jws , javax.jws.soap , javax.xml.soap e todos os pacotes javax.xml.ws.*
  • java.xml.ws.annotation com o pacote javax.annotation

Quais mantêm os artefatos de terceiros que fornecem essas APIs? Não importa quão bem eles forneçam essas APIs ou quais outros resources eles têm a oferecer – tudo o que importa é, eles são um substituto para esses módulos / pacotes?

Para facilitar a coleta de conhecimento, respondi com o que sei até agora e tornei a resposta um wiki da comunidade. Espero que as pessoas o estendam em vez de escrever suas próprias respostas.


Antes de votar para fechar:

  • Sim, já existem algumas questões sobre módulos individuais e uma resposta a essa pergunta, é claro, duplicaria essa informação. Mas a AFAIK não tem um único ponto para aprender sobre tudo isso, o que eu acho que tem muito valor.
  • As perguntas que pedem recomendações para bibliotecas geralmente são consideradas fora do assunto, porque “elas tendem a atrair respostas opiniosas e spam”, mas não acho que isso se aplique aqui. O conjunto de bibliotecas válidas é claramente delineado: elas precisam implementar um padrão específico. Além disso, nada mais importa, então não vejo muito risco de opinião e spam.

Em vez de usar os módulos Java EE obsoletos, use os seguintes artefatos.

JAF ( java.activation )

O JavaBeans Activiation Framework é uma tecnologia independente (disponível no Maven Central):

  com.sun.activation javax.activation 1.2.0  

( Fonte )

CORBA ( java.corba )

Do JEP 320 :

Não haverá uma versão independente do CORBA, a menos que terceiros façam a manutenção das APIs do CORBA, da implementação do ORB, do provedor do CosNaming etc. A manutenção de terceiros é possível porque o Java SE Platform endossa implementações independentes do CORBA. Em contraste, a API para RMI-IIOP é definida e implementada exclusivamente no Java SE. Não haverá uma versão independente do RMI-IIOP a menos que um JSR dedicado seja iniciado para mantê-lo, ou a administração da API seja assumida pelo Eclipse Foundation (a transição do gerenciamento do Java EE do JCP para o Eclipse Foundation inclui o GlassFish e a implementação do CORBA e do RMI-IIOP).

JTA ( java.transaction )

Versão autônoma:

  javax.transaction javax.transaction-api 1.2  

( Fonte ; dê uma olhada em como usar o 1.2 e o próximo 1.3 no caminho de class e módulo.)

JAXB ( java.xml.bind )

Implementação de referência:

      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  

( Fonte ; JEP 320 explica de onde obter schemagen e xjc .)

JAX-WS ( java.xml.ws )

Implementação de referência:

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

( Fonte ; também explica onde obter wsgen e wsimport .)

Anotações Comuns ( java.xml.ws.annotation )

Anotações do Java Commons (disponível no Maven Central):

  javax.annotation javax.annotation-api 1.3.1  

( Fonte )

JAXB (java.xml.bind) para JDK9

Trabalhando perfeitamente nos meus aplicativos de desktop no 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 o jaxws-ri depende transitivamente do commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852 que aparentemente pode ser encontrado no repository http://download.eclipse.org/rt/eclipselink/maven.repo