Simplificando Service Providers com módulos do Java 9+

A partir do Java 9, podemos definir módulos usando o JPMS (Java Platform Module System).

No arquivo module-info.java do Cotuba, vamos descrever o módulo cotuba:

Um módulo permite a criação de encapsulamento um nível acima de pacotes ou classes. É possível escolher quais pacotes de um JAR serão expostos para outros módulos.

Vamos exportar os pacotes:
- cotuba.plugin, que contém as interfaces LogoAposRenderizarMDParaHTML e AoFinalizarGeracao
- cotuba.domain, que contém as classes Ebook e Capitulo, entre outras.

Para isso, devemos usar o exports:

Usamos o requires para definir de quais outros módulos dependemos:

No Cotuba, usamos as bibliotecas Commons CLI, CommonMark, Epublib e iText. Cada um desses tem suas próprias dependências.

A equipe da Paradizo também modularizou o tema:

O tema da Paradizo depende da biblioteca JSoup e do módulo do Cotuba.

No caso de dependermos de um JAR ainda não modularizado, é criado um módulo automaticamente, que expõe todos os pacotes.

O nome do módulo automático será definido pela configuração Automatic-Module-Name do arquivo META-INF/MANIFEST.MF, o que acontece na biblioteca CommonMark.

Caso esse arquivo não exista, o nome do próprio JAR será usado. É o caso para as demais bibliotecas.

Com o JPMS ainda podemos executar a aplicação com um Classpath, por motivos de retrocompatibilidade. Porém, não teríamos as vantagens da modularização.

Para executarmos de maneira modularizada, devemos usar a opção --module-path. Além disso, precisamos usar a opção --module para indicar qual é o módulo da classe Main:

O resultado do comando anterior é o seguinte erro:

Quando usamos módulos do JPMS, precisamos mudar um pouco a maneira de definir os service providers e interfaces.

Usando a ServiceLoader API em módulos do JPMS

Em módulos do JPMS, as Service Provider Interfaces (SPI) devem ser definidas com o uses.

No módulo cotuba, teremos:

Já no código do tema da Paradizo, indicamos um service provider com provides ... with:

Podemos excluir o arquivo META-INF/services/cotuba.plugin.LogoAposRenderizarMDParaHTML, já que um módulo do Java 9 ignora esse arquivo.

A definição de SPIs com uses e de service providers com provides ... with nos módulos do JPMS simplifica o uso da Service Loader API.

Executamos com o mesmo comando anterior:

O resultado será:

O EPUB foi gerado com sucesso e a borda do no título do capítulo foi aplicada.

O código pode ser encontrado em:
https://github.com/alexandreaquiles/cotuba/tree/java9

Plugins na sua arquitetura

Há um estilo arquitetural em que o domain model é o núcleo da aplicação. Uma interface de linha comando seria um plugin. Uma aplicação Web seria outro plugin. A persistência em um banco de dados relacional, outro plugin. Persistência em um datastore NoSQL, mais um plugin. Integrações com outros sistemas, mais plugins.

Usando interfaces, invertemos as dependências para que todos dependam do domain model, que não depende de ninguém. As dependências sempre apontam na direção das regras de negócio, nunca ao contrário. Cada "mecanismo de entrega" seria um plugin diferente.

Teríamos uma melhor manutenibilidade, extensibilidade e testabilidade, mas ao custo de maior complexidade. Esse estilo arquitetural é detalhado na arquitetura hexagonal e na clean architecture.

No caso do Cotuba, o núcleo da aplicação poderia ficar no módulo cotuba. Extrairíamos a interface de linha de comando para o módulo cotuba.cli. A geração de PDFs para o módulo cotuba.pdf e de EPUBs para o módulo cotuba.epub. Definiríamos interfaces, criando contratos e invertendo as dependências entre esses módulos, sempre apontando na direção do módulo cotuba.

O desenvolvimento de cada módulo poderia ser feito por diferentes times. As interfaces dos plugins seriam muito importantes para a comunicação entre esses times.