Quase quatro meses depois do Sistema de Módulos da Plataforma Java (JPMS), também conhecido como Projeto Jigsaw e JSR 376, falhar na votação para aprovação da revisão publica original, o comitê executivo (EC) aprovou de forma esmagadora a votação de reconsideração. Como informado anteriormente pelo InfoQ, uma série de fatores que levaram os membros do comitê executivo (EC) IBM e Red Hat, a declarar publicamente que votariam não, bem antes do prazo da votação original, e outros fatores que também levaram o Twitter e a Comunidade Java de Londres a votar contra a aprovação..
Na votação de reconsideração, todos os membros do comitê executivo votaram "sim" com exceção da Red Hat, que recusou-se a votar. Nos comentários do voto, a Red Hat explicou:
A Red Hat está se abstendo neste momento porque, embora nós acreditamos que tivemos um progresso positivo com o Grupo de Especialistas (EG) para alcançar um consenso desde a última votação, nós acreditamos que existem alguns itens dentro da proposta atual que afeterão enormemente a adesão da comunidade e que poderiam ter sido discutidos dentro do período de extensão de 30 dias para este lançamento. Contudo, nós não queremos atrasar o lançamento do Java 9 e estamos satisfeitos com o cronograma mais agressivo proposto pelo líder da especificação e o Grupo de Especialistas (EG) para versões subsequentes do Java. Obter um retorno do mundo real do sistema de modularidade será fundamental para entender onde outras mudanças precisam acontecer. Nós esperamos que o líder do projeto e o Grupo de Especialistas (EG) continuem abertos para as entradas da comunidade Java em geral, como eles estiveram nos últimos 30 dias e esperamos que a evolução do Java seja conduzida por dados de usuários e comunidades além do OpenJDK.
O Twitter, tendo votado não na votação original, mudou de posição na votação de reconsideração. Tony Printezis, engenheiro JVM/GC do Twitter, explicou em seu blog:
O Grupo de Especialistas (EG) JSR 376 tem trabalhado duro para esclarecer diversas ambiguidades (#RestrictedKeywords, #CompilationWithConcealedPackages, and #ResolutionAtCompileTime) e fez algumas mudanças importantes (#ModuleNameIManifest e Relax Strong Encapsulation) na revisão da especificação JSR 376.
Como resultado deste trabalho, decidimos por votar "Sim" na evisão pública de reconsideração da JSR 376.
O relaxamento no encapsulamento forte por padrão deve ajudar a adoção do JDK 9, ao menos no curto prazo, removendo barreiras importantes. Existe agora um grande consenso entre o Grupo de Especialistas (EG) que, com estas mudanças, o Sistema de Módulos da Plataforma Java (JPMS) está pronto para ser lançado no JDK 9.
A comunidade Java de Londres também votou não na votação original e mudou o voto na votação de reconsideração. Martijn Verburg, co-fundador da comunidade Java de Londres e CEO da jClarity, e Tim Ellison, membro sênior da equipe técnica da IBM, falou para InfoQ sobre este último voto:
InfoQ: Qual é sua reação ao fato da Red Hat ter escolhido abster-se da votação?
Martijn Verburg: Eu gostaria de deixar claro que está é a minha opinião. Eu acho que a Red Hat votou desta maneira porque eles sentiram que um voto pelo "sim" poderia indicar para seus clientes que o Jigsaw (da forma atual) está pronto imediatamente para todos seus clientes e todos seus casos de uso. A Red Hat deixa bem claro que, embora Jigsaw na sua forma atual esteja uma base aceitável, ele não está pronto para todos os clientes e casos de uso.
Diversos itens para o Jigsaw que a Red Hat estava procurando resolver foram adiadas para datas futuras. A solução para estes itens não sabemos se virão no lançamento do update do Java 9 ou no Java 10.
InfoQ: O que mudou desde a votação do dia 8 de Maio?
Verburg: Muito! Os detalhes da especificação técnica estão abaixo:
- 18 de Maio de 2017, Rascunho do Grupo de Especialistas
- 22 de Maio de 2017, Rascunho do Grupo de Especialistas
- 23 de Maio de 2017, Rascunho do Grupo de Especialistas
Alguns destaques incluem:
- Acordo nos formatos dos nomes das versões.
- Acordo nas regras sobre Módulo de Nomeação Automatico e um guia de melhores maneiras de utilizá-los (importante para o ecosistemas Maven).
- A discussão em torno de como lidar com várias versões no mesmo módulo foi adiada para se resolver mais tarde.
- Acordo no afrouxamento do encapsulamento forte como padrão (significa que menos aplicativos saíram da caixa, mas receberam um alerta).
- A organização do uso de algumas palavras chaves (permitindo que o Eclipse funcione)
InfoQ: Houve outras mudanças/fatores de contribuições feitas no JSR-376 para que o voto fosse aprovado?
Verburg: Foi *muito" crucial o líder da especificação e o Grupo de Especialistas se reunirem, de verdade, na conferência e fazerem um esforço significativo para melhorarem a comunicação e a colaboração entre eles.
Ellison: Houve muitas mudanças técnicas desde que a votação foi encerrada no dia 08 de Maio [1]. Algumas destas são relativamentes melhorias menores na API, mesmo que se fosse possível a este ponto a especificação ter sido alterada para o status para Rascunho da Proposta Final. Outras são novas funcionalidades que suportam facilmente a migração do código existente e adoção mais ampla dos conceitos do Java 9 já estabelecidos nas bibliotecas e aplicativos. Como um grupo de especialistas, nos reunimos (virtualmente) e discutimos questões pendentes, decidindo quais delas "precisavam ser corrigidas" para o lançamento inicial, quais questões poderiam ser adiadas para versões posteriores do Java SE, e quais devem ser abandonadas nesta fase.
Existem algumas discussões dentro do JCP sobre a garantia da vitalidade e do ritmo das melhorias tecnológicas do Java SE, aumentando a cadência do lançamento da plataforma. Isso tem sido possível com a padronização de processos, que tem servido o Java muito bem durante muitos anos, e com o fórum onde interesses comerciais podem ser discutidos de forma produtiva.
Trazendo estes dois segmentos juntos, espero que alguns itens do Sistema de Módulos da Plataforma Java (JPMS), que foram adiados, possam ser reconsiderados em uma manutenção da release da pelo grupo de especialistas de forma muito rápida. Além disso, comprometendo-se para liberação inicial, quaisquer melhorias futuras se beneficiarão de algumas experiências do mundo real.
Eu escrevi um pouco mais sobre este assunto no blog[2], e a lista de questões pendentes está documentada aqui [3].
[1]https://www.jcp.org/en/jsr/results?id=5959
[2]https://developer.ibm.com/javasdk/2017/05/26/building-consensus-jsr-376-java-platform-module-system/
InfoQ: Há alguma outra mudança que você gostaria de ver feita na JSR-376?
Verburg: Eu gostaria de ver mais trabalhos sobre versionamento e suporte de versões. No momento, o ônus está ainda em desenvolver ferramentas para resolver isto, mas gostaríamos de ver uma orientação forte no Jigsaw sobre isto.
Ellison: Modularidade não é um design único. Eu acho que irá evoluir conforme as pessoas forem utilizando e forem levantando problemas que não previmos, para casos de usos que nós não tínhamos previsto, e adaptando mudanças da indústria (nuvem, microservices, serverless, etc). Meu foco sempre foi trabalhar com a comunidade e nos interesses dos nossos clientes para assegurar que o código atual não seja deixado para trás quando o Java SE evoluir, e que os novos frameworks o modelos de programação estejam bem suportados.