Sofrência com Java 9: cadê meu JAXB?

– Cara, cadê meu JAXB?
– Hein?

– Pô, cara, tava empolgadão aqui com o JDK 9. Atualizei e tal. Aí tentei subir uma aplicação no Tomcat e outra no Jetty e recebi isso na cara:

org.springframework.beans.factory.BeanCreationException: 
  Error creating bean with name 'entityManagerFactory' defined in ServletContext resource [/WEB-INF/spring-context.xml]: 
  Invocation of init method failed; 
    nested exception is java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1589)
	...
Caused by: 
  java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
  at org.hibernate.boot.spi.XmlMappingBinderAccess.(XmlMappingBinderAccess.java:43)

– Tô ligado. O famoso NoClassDefFoundError de JAXBException no Java 9.

– Não subiu por causa do JAXB? Ué, aquela biblioteca de serialização Java/XML? Mas eu nem uso nos meus projetos…
– Você não usa, mas alguma dependência pode usar. O Hibernate, no caso.

– E o JAXB não vem nas libs padrão do JRE?
– Vem, inclusive no JRE 9.

– Uai… Por que o erro, então?
– É que o JAXB tá nas libs padrão, mas não fica disponível… Aí, o Hibernate vai usar e: BAM!

Tomcat

– Como resolvo no Tomcat?
– Seta a variável de ambiente JAVA_OPTS, que o Tomcat usa pra pegar argumentos da JVM. Para deixar o JAXB disponível, usamos o argumento --add-modules com o valor java.xml.bind. Assim, ó:

export JAVA_OPTS="--add-modules java.xml.bind"

– E resolve mesmo?
– Se for só o JAXB que tiver faltando, resolve. Sei de um grande site brasileiro que simplesmente fez isso e tá rodando bonito em produção! Mas depende. Você pode ter outros problemas.

Jetty

– Uia! E no Jetty?
– É bem parecido, mas o nome da variável de ambiente é JAVA_OPTIONS. O valor vai ser igual. Tipo assim:

export JAVA_OPTIONS="--add-modules java.xml.bind"

Maven

– E se eu tiver rodando em desenvolvimento, com aquele plugin do Jetty pro Maven?
– Tipo mvn jetty:run?

– Isso!
– Ah, aí você pode usar a variável de ambiente MAVEN_OPTS. Tipo:

export MAVEN_OPTS="--add-modules java.xml.bind"

Se você tiver usando o goal jetty:run-forked, pode também usar a opção jvmArgs no pom.xml.

– Pro plugin do Tomcat deve ser parecido, né?
– Não vi, mas acho que sim…

Standalone

– Tá. E é só no Tomcat ou Jetty que dá esse pau?
– Não. Se seu código usar o JAXB, vai dar pau. Mesmo um código simples, tipo esse:

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
//...
public class Teste {
  public static void main(String[] args) throws JAXBException {
    JAXBContext ctx= JAXBContext.newInstance(Cliente.class);
    //...
  }
}

Vamos dizer que você tinha esse código compilado com o JDK 8.

Se tentar rodar no JRE 9, com java Teste, você vai tomar na cara uma exceção parecida com a do Tomcat e do Jetty:

Error: Unable to initialize main class Teste
Caused by:
  java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

– E se essa classe tiver num JAR?
– Vai dar o mesmo erro quando você fizer o java -jar teste.jar.

– Como resolve?
– Precisamos usar aquela tretinha também ao executar:

java --add-modules java.xml.bind Teste

– Então com o JAR vai ser: java --add-modules java.xml.bind -jar teste.jar?
– Isso mesmo!

– Opa! Aí sim! E se eu não usar o JAXB no meu código? Vai funcionar?
– Provavelmente sim. Mas tem outras coisas que podem dar um pau parecido. Então, não dá pra dizer…

Compilando

– Mas e se eu tentar compilar com o JDK 9?
– Se usar o JAXB, vai dar pau logo de cara. Se você fizer javac Teste.java vai rolar erro de compilação já nos imports:

Teste.java:1: error: package javax.xml.bind is not visible
import javax.xml.bind.JAXBContext;
                ^
 (package javax.xml.bind is declared in module java.xml.bind, which is not in the module graph)
Teste.java:2: error: package javax.xml.bind is not visible
import javax.xml.bind.JAXBException;
                ^
 (package javax.xml.bind is declared in module java.xml.bind, which is not in the module graph)
2 errors

Para compilar com sucesso, tem que passar o tal --add-modules:

javac --add-modules java.xml.bind Teste.java

Aí compila tudo direitinho!

– E se tiver usando o Maven pra compilar esse código?
– Se as propriedades maven.compiler.source e maven.compiler.target tiverem até 1.8, não tem problema.

– Mesmo se eu só tiver o JDK 9 na máquina pra compilar?
– Sim. Porque o plugin de compilação do Maven não usa o javac, pelo menos do 3.0 pra frente.

– Caramba! Mas e se eu pôr <maven.compiler.source>1.9<maven.compiler.source>?
– Aí, ferra… Vai dar aquele erro de compilação dizendo que o pacote javax.xml.bind não é visível.

– E como arruma?
– Tem que configurar o plugin de compilação do Maven e passar o famoso --add-modules. Tipo assim:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.7.0</version>
  <configuration>
    <compilerArgs>
      <arg>--add-modules</arg>
      <arg>java.xml.bind</arg>
    </compilerArgs>
  </configuration>
</plugin>

Repare que não pode colocar num elemento <arg> só, porque não pode ter espaço no valor.

– Vai entender…
– Pois é…

Eclipse

– Dá pra rodar o Java 9 com o Eclipse?
– Hmmm… Até dá, se você baixar a última versão, a Oxygen 1a. Aliás, foi lançada hoje! Antes tinha que instalar um plugin.

Um detalhe interessante é que, lá no eclipse.ini, o parâmetro -vmargs tem o valor --add-modules=ALL-SYSTEM.

– Meio parecido com o que a gente usou nas variáveis de ambiente mas o valor é diferente, né?
– Exato!

– E aí posso criar um projeto Java 9 no Eclipse?
– Sim. É só escolher o execution environment JavaSE-9 ou apontar pra um JRE 9 específico para o projeto.

– O código lá que usa o JAXBContext vai compilar de cara nesse projeto?
– O pior é que não…

– Poxa…
Assim… Se não usasse diretamente o JAXB, compilaria de boa. Tipo as suas aplicações, que não dependem direto JAXB. É o Hibernate que depende, mas você não precisa compilar. Você pega os .class do JAR.

– Sei…
Mas como esse código da classe Teste usa diretamente o JAXBContext, não dá não…

Precisamos ir no Build Path do projeto e, no Modulepath, editar a configuração Is modular do JRE 9 do seu projeto:

– Tá, mas e aí?
– Aí, na tela de Module properties, coloque o java.xml.bind de Available para Explicitly included

– Aí compila?
– Opa! Sucesso! Só que ao rodar com o JRE 9, vai dar o pau de NoClassDefFoundError de JAXBException.

– Eita!
– Pois é… Vamos ter que ir no Run Configurations > Java Application > Arguments > VM Arguments e pôr --add-modules java.xml.bind.

Aí deve rodar de boa!

– E se tiver rodando o Maven por dentro do Eclipse?
– Vai ser parecido. Dá erro ao rodar. Aí, tem que ir no Run Configurations > JRE > VM Arguments e colocar --add-modules java.xml.bind pra arrumar.

JAXB como dependência

– Tem outra maneira de resolver sem usar essa treta de --add-modules?
– Sempre tem, né? Se não quiser usar esse argumento da JVM, dá pra colocar a API e uma implementação do JAXB como dependência do seu projeto.

– Como assim?
– Tipo, botar no pom.xml isso daqui:

<dependency>
  <groupId>javax.xml.bind</groupId>
  <artifactId>jaxb-api</artifactId>
  <version>2.2.11</version>
</dependency>
<dependency>
  <groupId>com.sun.xml.bind</groupId>
  <artifactId>jaxb-core</artifactId>
  <version>2.2.11</version>
</dependency>
<dependency>
  <groupId>com.sun.xml.bind</groupId>
  <artifactId>jaxb-impl</artifactId>
  <version>2.2.11</version>
</dependency>

– Ah, entendi…
– Na real, essa é a solução mais recomendada. A do --add-modules vai dar pau nas próximas versões.

Bibliotecas

– Hmmm… E como as bibliotecas tem resolvido essas questões?
– Você diz para os caras compilarem no JDK 9 e, quem for usar, puder rodar no JRE 9?

– Sei lá… Acho que é…
– Ah, as últimas versões do Hibernate e do Spring fizeram esse esquema de depender de uma implementação do JAXB e de outras bibliotecas que eles usam. Já o JOOQ, decidiu deixar que o usuário coloque --add-modules por enquanto, até que modularize o JOOQ pra valer. O Jetty também deixou pro usuário e, pra compilar, usaram --add-modules java.se.ee.

– Tá meio diferente do nosso, o valor do --add-modules, né?
– É!

O porquê

– Tá entendi como resolver pra uma série de ferramentas. Mas por que diabos acontece esse erro no Java 9 e não acontecia antes?
– Bom. Acho que você já ouviu falar que a grande novidade do Java 9 é o conceito de módulos e a modularização do próprio JDK.

– Sim, sim.
– O JDK tem o módulo java.base que é o fundamento. Nesse módulo tão os pacotes java.lang, java.util, java.time, java.text, java.io…

– Aqueles que a gente sempre usa, né?
– Isso! Aí tem uns que a gente nem usa tanto, né? Tipo o módulo java.rmi, o java.desktop que tem os pacotes pra fazer telinhas Swing/AWT. Esses tão fora do java.base.

– E o Java FX?
– Esse tá em uma série de outros módulos: javafx.base, javafx.controls, javafx.fxml, javafx.web e por aí vai… Também tão fora do base.

– Saquei…
– Uma coisa curiosa é que não tão no base os dois módulos de JDBC, java.sql e java.sql.rowset, e nem o java.logging.

– É mesmo?
– É. Aí, se você quiser criar um novo projeto com o Java 9 e quer que ele seja explicitamente modularizado, você tem definir uma pasta com o nome do módulo e dentro um arquivo module-info.java e os pacotes. Tipo assim:

projeto
  └── src
    └── br.com.empresa
        └── module-info.java
        └── br
             └── com
                 └── empresa
                     └── Teste.java

Detalhe que pasta dentro do src é br.com.empresa com os pontos mesmo. Já o pacote é uma pasta dentro da outra.

– Bacana.
– Aí, esse seu módulo br.com.empresa vai depender apenas do módulo java.base. Se você quiser usar o JDBC, por exemplo, você tem que pôr dentro do module-info.java:

module br.com.empresa {
  requires java.sql;
}

Isso para um projeto novo, do Java 9 e modularizado.

– Tá.
– Agora, imagina que pegamos um WAR ou JAR compilado com o JDK 8 e queremos rodar no JRE 9.

– Java é retro-compatível, ué! Devia funcionar…
– Né? Pra boa parte dos projetos vai funcionar sim. Mas pra alguns casos vai dar pau…

– É a vida…
– Uma coisa é certa: as classes compiladas com o JDK 8 não tem módulos. Mas o JRE 9 sempre precisa de módulos pra rodar.

– Mas como ele faz então?
– O JRE 9 roda código sem módulos no “módulo sem nome”. Parece coisa de filme de terror, não?

– É… hehe
– E esse “módulo sem nome” oferece para aplicação automaticamente o módulo java.se, que junta uma penca de coisa. A ideia é que tenha tudo o que uma aplicação Java SE antiga precisa pra rodar: além do java.base, tem o java.logging, o java.sql, o java.rmi, etc…

– Entendi..
– Na real, você ainda pode programar em Java 9 sem módulos, do jeito antigo. É só não definir aquela pasta com o module-info.java no src e colocar direto os pacotes. Aí, você vai estar em um “módulo sem nome”.

– E vai depender automaticamente do java.se
– Boa! Mas tem coisa que fica de fora desse java.se mas que tava disponível nas versões antigas do JRE.

– Tipo o JAXB?
– Isso mesmo! O JAXB tá no módulo java.xml.bind mas não vem por padrão numa aplicação que está no “módulo sem nome”.

– Ah….
– Daria pra modularizar o projeto e, no module-info.java colocar o requires java.xml.bind. Mas dá trabalho, né?

– Dá trabalho sim.
– Então, o povo inventou esse argumento da VM pra oferecer módulos a mais pra aplicação: o --add-modules.

– Agora entendi… Mas, vem cá, por que eles tiraram o JAXB, pô?!
– O JAXB e algumas outras APIs são coisa do Java EE e não do SE. Só que vinham embutidos no JRE. Algumas bibliotecas e aplicação usavam. Agora, vão remover. Se você olhar no Javadoc, o módulo java.xml.bind tá deprecated for removal.

– Vão arrancar mesmo?
– Sim, mas só no futuro…

– E quais APIs do Java EE tão nessa situação?
– Ah, tem a implementação do JAX-WS que vinha embutida no JRE, que tá nos módulos java.xml.ws e o java.xml.ws.annotation.

– Aquela especificação pra WebServices SOAP vinha embutida no JRE? Não sabia…
– Pois é. Não é muito usado. Mas dá pra fazer fora de um servidor de aplicação isso daqui:

Endpoint.publish("http://localhost:9090/EstoqueWS", 
    new EstoqueWS());

– Ó! Tem outros módulos do Java EE que vem no JRE?
– Tem também o java.corba, o java.activation e o java.transaction.

– Todos esses serão removidos no futuro também?
– Sim.

– Deve ter uma galerinha que usa o JAXB e o JAX-WS…
– O JAXB sim. O JAX-WS nem tanto, porque o povo usa a implementação do servidor de aplicação.

– Poderiam ter deixado esse módulo java.xml.bind no java.se, né?
– Também acho!

– …
– Aí, tem uma outra coisa: tem um módulo que junta isso tudo do Java EE que vai ser removido. É o módulo java.se.ee. E depende também do java.se.

Essa figura do Paul Bakker mostra bem quais são esses módulos do java.se.ee.

– Daria pra usar --add-modules java.se.ee então?
– Sim, mas viria mais coisas que o JAXB.

– É o que você tinha dito que o povo do Jetty fez pra compilar, né?
– Isso!

– E no eclipse.ini tinha --add-modules ALL-SYSTEM. Que isso?
– É um módulo que inclui tudo mesmo, inclusive coisas específicas do JDK. Aí, vão vir aquelas classes que começam com com.sun. Ninguém devia depender dessas classes, mas vai ver o Eclipse precisa de algo, né?

– Só pra lembrar, qual é a solução mais indicada mesmo?
– O melhor mesmo é depender de uma implementação do JAXB ou da outra lib que tiver faltando. Até segundo a turma da Oracle.