Migrando para módulos

Poucos projetos adotam módulos desde o primeiro dia. O JPMS foi projetado para a migração gradual, permitindo que o caminho de classes e o caminho de módulos coexistam.

Os conceitos fundamentais são os módulos automáticos e o módulo não nomeado.

Tudo o que é carregado do caminho de classes vive no único módulo não nomeado. Ele lê todos os outros módulos e exporta todos os seus pacotes.

Essa é a ponte que mantém o código legado do caminho de classes funcionando.

Uma regra crucial: um módulo nomeado explícito não pode depender do módulo não nomeado. Não é possível escrever requires para código do caminho de classes.

Por isso, faça a migração de baixo para cima: primeiro converta a forma como as dependências são representadas.

Coloque um JAR simples (não modular) no caminho de módulos, e ele se tornará um módulo automático. Ele receberá um nome derivado automaticamente, lerá todos os outros módulos e exportará todos os seus pacotes.

Isso permite que módulos nomeados declarem requires para um JAR que ainda não tem module-info.

O nome de um módulo automático é derivado na seguinte ordem de preferência:

• A entrada Automatic-Module-Name no manifesto do JAR, caso esteja presente
• Caso contrário, do nome do arquivo JAR (com a versão removida e os hífens convertidos em pontos)

Os autores de bibliotecas devem adicionar Automatic-Module-Name ao manifesto antes de modularizar completamente. Isso garante um nome de módulo estável, para que as cláusulas requires posteriores sobrevivam ao eventual module-info real.

A abordagem recomendada para sua própria aplicação:

• Mantenha as dependências como módulos automáticos no caminho de módulos
• Adicione primeiro um module-info.java ao seu módulo superior
• Declare requires para os nomes desses módulos automáticos

Suponha que guava-32.jar esteja no caminho de módulos como o módulo automático com.google.common. Seu módulo de aplicação já pode declarar uma dependência dele.

O sistema de módulos proíbe que dois módulos contenham o mesmo pacote. Bibliotecas antigas que dividem um pacote entre JARs causam erros.

Corrija isso mesclando os JARs, usando --patch-module ou atualizando para versões que eliminem a divisão.

Estruturas que fazem reflexão profunda podem falhar com InaccessibleObjectException depois que você modulariza o código. Adicione diretivas opens ou, como ponte temporária, use a opção de inicialização --add-opens.

A ferramenta jdeps analisa seus JARs, informa dependências, sinaliza usos de APIs internas do JDK e pode até gerar um module-info.java candidato com jdeps --generate-module-info.

Execute-a primeiro para planejar sua migração.

Relembre como um JAR simples obtém uma identidade de módulo.

Você aprendeu técnicas de migração:

• O código do caminho de classes vive no módulo não nomeado; módulos nomeados não podem declarar dependências dele
• JARs simples no caminho de módulos se tornam módulos automáticos
• Defina Automatic-Module-Name para obter nomes estáveis
• Fique atento a pacotes divididos e ao acesso por reflexão; use jdeps para planejar

Isso conclui o curso de JPMS.