Noções básicas sobre os módulos do Java 9

O que são e como usá-los

Por Paul Deitel

Neste artigo, apresento o Java 9 Platform Module System (JPMS), a nova tecnologia de engenharia de software em Java mais importante desde sua origem. A modularidade – o resultado do Project Jigsaw – ajuda os desenvolvedores em todos os níveis a serem mais produtivos à medida que criam, mantêm e desenvolvem sistemas de software, especialmente sistemas complexos.

O que é um módulo?

A modularidade adiciona um nível mais alto de agregação acima dos pacotes. O novo elemento chave da linguagem é o módulo – um grupo reutilizável com nomes exclusivos de pacotes relacionados, bem como recursos (como imagens e arquivos XML) e um descritor de módulo especificando

• o nome do módulo
• as dependências do módulo (ou seja, outros módulos dos quais este módulo depende)
• os pacotes que ele disponibiliza explicitamente para outros módulos (todos os outros pacotes do módulo estão implicitamente indisponíveis para outros módulos)
• os serviços que ele oferece
• os serviços que ele consome
• a quais outros módulos ele permite reflexão

Histórico

A plataforma Java SE existe desde 1995. Atualmente, existem cerca de 10 milhões de desenvolvedores que o utilizam para criar tudo, desde pequenos aplicativos para dispositivos com recursos limitados, como os da Internet das Coisas (IoT) e outros dispositivos incorporados, até sistemas de negócios e de missão críticos em grande escala. Existe uma grande quantidade de código legado, mas até agora a plataforma Java tem sido principalmente uma solução monolítica de tamanho único. Ao longo dos anos, houve vários esforços orientados para a modularização do Java, mas nenhum é amplamente usado, e nenhum poderia ser usado para modularizar a plataforma Java.

A modularização da plataforma Java SE tem sido um desafio para a implementação, e o esforço levou muitos anos. JSR 277: Java Module System foi originalmente proposto em 2005 para o Java 7. Posteriormente, esse JSR foi substituído pelo JSR 376: Java Platform Module System e direcionado para o Java 8. A plataforma Java SE agora é modularizada no Java 9, mas somente após o Java 9 ter sido adiado até setembro de 2017.

Metas

De acordo com a JSR 376, os principais objetivos da modularização da plataforma Java SE são

• Configuração confiável – A modularidade fornece mecanismos para declarar explicitamente dependências entre módulos de uma maneira que é reconhecida tanto em tempo de compilação quanto em tempo de execução. O sistema pode percorrer essas dependências para determinar o subconjunto de todos os módulos necessários para oferecer suporte ao seu aplicativo.
• Encapsulamento forte – os pacotes em um módulo são acessíveis a outros módulos somente se o módulo os exportar explicitamente. Mesmo assim, outro módulo não pode usar esses pacotes, a menos que declare explicitamente que requer os recursos do outro módulo. Isso melhora a segurança da plataforma porque menos classes são acessíveis a possíveis invasores. Talvez descubra que considerar a modularidade pode ajudar a criar designs mais limpos e lógicos.
• Plataforma Java escalável – Anteriormente, a plataforma Java consistia em um grande número de pacotes, tornando-o em algo difícil desenvolver, manter e evoluir. Não poderia ser facilmente separado em subconjuntos. A plataforma agora é dividida em 95 módulos (esse número pode mudar conforme o Java evolui). Você pode criar tempos de execução personalizados que consistem apenas em módulos necessários para seus aplicativos ou dispositivos que está direcionando. Por exemplo, se um dispositivo não oferece suporte a GUIs, você pode criar um runtime que não inclua os módulos GUI, reduzindo significativamente o tempo de execução.
• Maior integridade da plataforma – Antes do Java 9, era possível usar várias classes na plataforma que não se destinavam ao uso pelas classes de um aplicativo. Com encapsulamento forte, essas APIs internas são realmente encapsuladas e ocultas dos aplicativos que usam a plataforma. Isso pode tornar problemática a migração do código legado para o Java 9 modularizado se o seu código depender de APIs internas.
• Desempenho aprimorado – A JVM usa diversas técnicas de otimização para melhorar o desempenho da aplicação. A JSR 376 indica que essas técnicas são mais eficazes quando se sabe com antecedência que os tipos necessários estão localizados apenas em módulos específicos.

Listando os módulos do JDK

Um aspecto fundamental do Java 9 é dividir o JDK em módulos para oferecer suporte a várias configurações. (Consulte "JEP 200: O JDK Modular." Todos os JSRs e JEPs de modularidade em Java são exibidos na Tabela 1.) Usando o comando java da pasta bin do JDK com a opção --list-modules, como em:

java --list-modules

lista o conjunto de módulos do JDK, que inclui os módulos padrão que implementam a Java Language SE Specification (nomes que começam com java), módulos JavaFX (nomes começando com javafx), JDK -módulos específicos (nomes que começam com jdk) e módulos específicos da Oracle (nomes que começam com oracle). Cada nome de módulo é seguido por uma string de versão—@9 indica que o módulo pertence ao Java 9.

Declarações do módulo

Conforme mencionamos, um módulo deve fornecer um descritor de módulo – metadados que especificam as dependências do módulo, os pacotes que o módulo disponibiliza para outros módulos e muito mais. Um descritor de módulo é a versão compilada de uma declaração de módulo definida em um arquivo chamado module-info.java. Cada declaração de módulo começa com a palavra-chave module, seguida por um nome de módulo exclusivo e um corpo de módulo entre chaves, como em:

module modulename { 
}

O corpo da declaração do módulo pode estar vazio ou pode conter várias diretivas de módulo, incluindo requires, exports, provides…with, uses e opens (cada um dos quais discutimos). Como você verá mais adiante, compilar a declaração do módulo cria o descritor do módulo, que é armazenado em um arquivo chamado module-info.class na pasta raiz do módulo. Aqui apresentamos brevemente cada diretiva de módulo. Depois disso, apresentaremos as declarações reais do módulo.

As palavras-chave exports, module, open, opens, provides, requires, uses, with, bem como to e transitive, que apresentaremos posteriormente, são palavras-chave restritas. Elas são palavras-chave apenas em declarações de módulo e podem ser usadas como identificadores em qualquer outro lugar no seu código.

requires. Uma diretiva de módulo requires especifica que este módulo depende de outro – esse relacionamento é chamado de dependência de módulo. Cada módulo deve declarar explicitamente suas dependências. Quando o módulo A requer o módulo B, diz-se que o módulo A lê o módulo B e o módulo B é lido pelo módulo A. Para especificar uma dependência em outro módulo, use requires, como em:

requires modulename;

Há também uma diretiva requires static para indicar que um módulo é necessário em tempo de compilação, mas é opcional no runtime. Isso é conhecido como dependência opcional e não será discutido nesta introdução.

requires transitive—implied readability. Para especificar uma dependência em outro módulo e garantir que outros módulos lendo seu módulo também leiam essa dependência – conhecida como implied readability – use requires transitive, como em:

requires transitive modulename;

Considere a seguinte diretiva da declaração do módulo java.desktop:

requires transitive java.xml; 

Nesse caso, qualquer módulo que lê java.desktop também lê implicitamente java.xml. Por exemplo, se um método do módulo java.desktop retornar um tipo do módulo java.xml, o código em módulos que leem java.desktop se tornará dependente de java.xml. Sem a diretiva requires transitive na declaração do módulo java.desktop, esses módulos dependentes não serão compilados, a menos que explicitamente leiam java. xml.

De acordo com JSR 379, os módulos padrão do Java SE devem conceder legibilidade implícita em todos os casos, como aquele descrito aqui. Além disso, embora um módulo padrão Java SE possa depender de módulos não padrão, ele não deve conceder legibilidade implícita a esses módulos. Isso garante que o código que depende apenas dos módulos padrão Java SE seja portátil em implementações do Java SE.

exports and exports…to. Uma diretiva de módulo exports especifica um dos pacotes do módulo cujos tipos public (e seus tipos public e protected aninhados) deve ser acessível ao código em todos os outros módulos. Uma diretiva exports…to permite especificar em uma lista separada por vírgulas precisamente qual código do módulo ou dos módulos pode acessar o pacote exportado – isso é conhecido como exportação qualificada.

uses. Uma diretiva de módulo uses especifica um serviço usado por este módulo—tornando o módulo um consumidor de serviço. Um serviço é um objeto de uma classe que implementa a interface ou estende a classe abstract especificada na diretiva uses.

provides…with. Uma diretiva de módulo provide…with especifica que um módulo fornece uma implementação de serviço – tornando o módulo um provedor de serviço. A parte provides da diretiva especifica uma interface ou classe abstract listada na diretiva uses de um módulo e a parte with da diretiva especifica o nome da classe do provedor de serviço que implements (implementa) a interface ou extends (estende) a classe abstract.

open, opens, and opens…to. Antes do Java 9, a reflexão podia ser usada para aprender sobre todos os tipos em um pacote e todos os membros de um tipo—até mesmo seus membros private – se quisesse permitir esse recurso ou não. Assim, nada foi realmente encapsulado.

Uma motivação importante do sistema de módulos é o encapsulamento forte. Por padrão, um tipo em um módulo não é acessível a outros módulos, a menos que seja um tipo público e você exporte seu pacote. Você expõe apenas os pacotes que deseja expor. Com o Java 9, isso também se aplica à reflexão.

Permitindo o acesso somente runtime a um pacote. Uma diretiva de módulo "opens" do formulário

opens package

indica que os tipos public de um pacote específico (e seus tipos public e protected aninhados) são acessíveis ao código em outros módulos apenas no runtime. Além disso, todos os tipos no pacote especificado (e todos os membros dos tipos) são acessíveis via reflexão.

Permitir acesso somente runtime a um pacote por módulos específicos. Uma diretiva do módulo opens…to do formulário

abre o pacote para a lista de módulos separados por vírgulas

indica que os tipos public de um pacote específico (e seus tipos public e protected aninhados) são acessíveis ao código nos módulos listados apenas no runtime. Todos os tipos no pacote especificado (e todos os membros dos tipos) são acessíveis via reflexão para codificar nos módulos especificados.

Permitir acesso somente runtime a todos os pacotes em um módulo. Se todos os pacotes em um determinado módulo tiverem acesso no runtime e via reflexão para todos os outros módulos, você pode open (abrir) o módulo inteiro, como em:

open module modulename {
   // module directives
} 

Padrões de reflexão

Por padrão, um módulo com acesso runtime reflexivo a um pacote pode ver os tipos public do pacote (e seus tipos public e protected aninhados). No entanto, o código em outros módulos pode acessar todos os tipos no pacote exposto e todos os membros desses tipos, incluindo membros private via setAccessible, como nas versões anteriores do Java.

Para obter mais informações sobre setAccessible e reflexão, consulte a documentação da Oracle.

---

Paul Deitel, CEO e Diretor Técnico da Deitel & Associates, é formado pelo MIT com 35 anos de experiência em computação. Ele é um Java Champion e trabalha com programação em Java há mais de 22 anos. Ele e seu coautor, Dr. Harvey M. Deitel, são os autores de linguagens de programação mais vendidos do mundo. Paul ministrou cursos de programação Java, Android, iOS, C#, C++, C e programação de internet para clientes do setor, governamentais e acadêmicos no mundo todo.

NOTA: Este artigo foi extraído da Java Magazine de setembro/outubro de 2017.