BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Oracle defende o sistema de módulos do Java

Oracle defende o sistema de módulos do Java

Favoritos

Uma das apresentação mais longas na conferência "Emerging Technologies for the Enterprise (ETE)" foi feita por Karen Kinnear, líder da JVM na Oracle, intitulada Java Futures: Módulos e Mais. Muita coisa aconteceu desde a apresentação, principalmente os eventos antes e depois do dia 8 de maio de 2017 referente à votação da JSR 376.

Kinnear apresentou os objetivos do Java 9, incluindo melhorias na produtividade durante o desenvolvimento e melhorias das APIs do Java para computação em nuvem. Depois da revisão da JEPs do Java 9, ela focou no novo sistema de módulos do Java (JPMS), também conhecido como Projeto Jiqsaw e JSR 376.

Kinnear encorajou a platéia a ter em mente três questões com relação ao sistema de módulos:

  • Está faltando alguma coisa?
    • O sistema de módulos irá detectar módulos que estão faltando ao construir o gráfico de módulos.
  • Existe algum conflito?
    • Conflitos entre pacotes também serão detectados ao construir o gráfico de módulos.
  • É seguro alterar uma API interna?
    • O sistema de módulos garantirá que uma API interna não pode ser acessada fora do módulos.

Módulos podem ser integrados em aplicações existentes, sustentou Kinnear. Ela demonstrou a interação e acessibilidade entre módulos e pacotes, enfatizando a distinção entre o module path e o classpath. Ela discutiu como os desenvolvedores podem migrar para o Java 9, particularmente quando existem alterações incompatíveis, mas ainda assim mantendo o compatibilidade com versões anteriores.

Mark Reinhold, arquiteto chefe da plataforma Java na Oracle, descreveu os objetivos das JPMS no seu relatório de março de 2016, como sendo:

  • Configuração confiável
    • substituir o mecanismo frágil e suscetível a erro do classpath por uma maneira onde os componentes declaram explicitamente as dependências uma sobre a outra.
  • Forte encapsulamento
    • permitir um componente declarar quais dos seus tipos públicos são acessíveis para outros componentes, e quais não são.

Respostas da Comunidade

Scott Stark, responsável pela arquitetura do JBoss na Red Hat, falou sobre suas preocupações com relação o sistema de módulos, notavelmente o que a Red Hat acreditava ser uma falha no comprimento da maiorias dos objetivos da JSR. Stark disse:

A implementação do Jiqsaw é um novo sistema de módulos o qual tem funcionado perfeitamente para a modularização do próprio Java, mas não foi amplamente testado nos deploys de produção de alguma aplicação real construídas sobre a JVM. Muitos casos de uso de deploys em produção utilizados nos dias de hoje, não são possíveis utilizando Jigsaw sendo necessária uma significativa reorganização da arquitetura.

IBM e Red Hat declararam publicamente que eles não irão votar a favor da JPMS na sua forma atual.

Independentemente da falta de consenso, Reinhold enviou a JSR 376 para revisão pública, alegando que era "na melhor das intenções do amplo ecossistema do Java continuar com a JSR, para que possa ser entregue de acordo com o objetivo estabelecido". No dia da votação da revisão pública, ele também enviou uma carta aberta para o comitê executivo (EC), encorajando-o a votar a favor da JSR 376. No entanto, independente de seus esforços, a JSR 376 não foi aprovado na revisão pública.

Depois da reprovação

Tony Printezis, engenheiro JVM/GC no Twitter, explicou a razão do voto negativo do Twitter feito no dia 8 de maio. Depois de discutir os benefícios da JPMS e Java 9, ele disse:

Nossa principal preocupação com relação a JPMS é que ela muito provavelmente irá ser problemática para os desenvolvedores Java, porque ela não fornece um benefício imediato que seria esperado de tal sistema. Estamos preocupados que isso irá atrasar a adoção em grande escala desta importante tecnologia. Esperamos que se a JPMS cumprir alguns dos seus objetivos originais de maneira mais compreensível, ela também aborde problemas reais que os desenvolvedores Java tem hoje em dia. Em particular: conflitos em nomes de pacotes não exportados são possivelmente incompatíveis com os objetivos da JSR no que se refere às "não-interferências" e "encapsulamento forte". Mas se os módulos fossem isolados completamente, seria o suficiente permitir construir sistemas que suportam múltiplas cópias do mesmo pacote por ocultá-los nos módulos como pacotes não exportados. Tais benefícios tangíveis e imediatos poderiam livrar os desenvolvedores da trabalhosa modularização que teria que ser feita no código fonte e contribuiria para uma adoção mais rápida da JPMS.

Numa entrevista para a InfoWorld, Reinhold tentou esclarecer alguns equívocos com relação a JPMS. Sobre uma das objeções mais comuns de que o Maven não funcionaria no Java 9, Reinhold disse que não era verdade: "Maven funciona perfeitamente no Java 9". Mas ele reconheceu que houve problemas com os plugins do Maven, incluindo um pequeno problema com o plugin de teste Surefire.

Com relação a preocupação dos desenvolvedores se suas bibliotecas, frameworks e ferramentas iriam funcionar no Java 9 ou não, Reinhold reconheceu que isso pode ser verdade para alguns elementos, mas disse que há uma boa chance que irá funcionar em ambientes de produção. Ele mencionou que os mantenedores de projetos tem tido acesso prévio ao Java 9, para que eles possam adaptar o código fonte para a nova versão. Por isso que projetos, tais como o Spring Boot e Hibernate Validator, vão funcionar no Java 9, disse Reinhold de acordo com a InfoWorld.

Entre os desenvolvedores, muitos acreditam que não seria possível utilizar o Java 9 até que eles convertessem todo o código fonte, frameworks e bibliotecas já existentes para o sistema de módulos. Reinhold novamente disse que isso não é verdade:

Os desenvolvedores ainda podem utilizar o classpath no Java 9 para buscar classes e arquivos e outros recursos. É que com os sistema de módulos do Java 9, os desenvolvedores não irão mais precisar do classpath.

Martjin Verburg, co-fundador da comunidade Java em Londres e CEO da jClarity, conversou com a InfoQ sobre os votos da JSR 376. Quando questionado sobre os benefícios de uma JVM modularizada, Verburg disse:

Ela fornece uma quantidade muito grande de segurança em torno do core do Java; oculta várias APIs do Java que são internas ou que não são seguras para utilização no dia-a-dia do desenvolvedor Java. Existe uma lacuna aí em que algumas funcionalidades necessitam ter suas dependências fornecidas de uma maneira segura. Existe um forte compromisso em criar pacotes pequenos do Java em tempo de execução, uma vez que o Java é separado em conjuntos de módulos menores. A ferramenta jlink, que estará disponível no Java 9, irá permitir que o deploy das aplicações sejam muito menores nos ambientes, instalando apenas o que elas precisam. Um exemplo clássico é que uma aplicação server-side não irá precisar de nenhuma biblioteca que são necessárias para aplicações desktop, como AWT ou Swing. Isto irá permitir ao Java iniciar muito mais rápido e rodar as coisas em dispositivos pequenos, bem como deploys mais rápidos nas infraestruturas de cloud.

Tim Ellison, funcionário sênior na IBM, recentemente descreveu como gerar um consenso sobre a JSR 376. Ele declarou:

Estamos ansiosos para ver está especificação revisada ser reapresentada para o JCP EC, e esperamos que o EC dê suporte ao Expert Group na sua conclusão. É de interesse da IBM a compatibilidade e o plano de migração de aplicações comerciais para o Java 9. Houve importantes mudanças relacionadas à migração e o comportamento padrão da JPMS que acreditamos ser muito valiosas.

A JSR 376 está confirmada para o próximo passo, o Esboço Final da Especificação Proposta (do inglês Proposed Final Draft Specification). Podem haver poucas modificações antes de se tornar uma especificação final, mas o processo em que ela tem se submetido demonstra que o JCP está trabalhando para fornecer uma funcionalidade poderosa para o Java. Crédito para a Oracle como líder da especificação e para aqueles que fazem parte do Expert Group que dedicaram seu tempo para alcançar este objetivo.

Reinhold recentemente propôs uma mudança na agenda a liberação GA do Java 9. Ele disse:

De maneira a estar preparada para qualquer desfecho, eu sugiro que aqui no Projeto JDK 9 continuemos a trabalhar em direção ao objetivo atual de produzir uma Release Candidate inicial para o dia 22 de junho [6], porém ajustar a data do GA para que tenhamos tempo necessário para passar pelo processo do JCP. Para ser específico, proponho que alteremos a data do GA para mais 8 semanas, do dia 27 de julho para o dia 21 de setembro.

O voto sobre a revisão pública da JSR 376 estava agendada para o dia 26 de junho. Fique de olho nas novidades sobre esse assunto!

Referências

Nota do Editor

Michael Redlich tem sido um participante ativo do ETE desde 2008 como participante, palestrante, e mais recentemente como um membro do ETE Steering Committee desde 2013.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT