O Java Community Process (JCP) publicou o resultado final da votação do Comitê Executivo do JCP sobre a JSR-376 (Java Platform Module System), popularmente conhecida como Jigsaw. 10 integrantes do Comitê votaram favoráveis à JSR enquanto 13 integrantes votaram contra a proposta de modularização.
A última semana foi marcada por intensos e profundos debates em torno do assunto. Mais recentemente, Mark Reinhold, Arquiteto Chefe do Java Platform Group na Oracle, publicou uma carta aberta ao Comitê Executivo do JCP onde diz:
"Ao analisar como será seu voto, peço que façam uma análise cuidadosa dos méritos da especificação e que levem em conta o precedente que essa votação poderá criar."
Ao que parece, o Comitê levou a sugestão a sério, registrando alguns comentários que indicam que a proposta ainda não se encontra pronta para ser aceita. Parte das preocupações estão relacionadas ao Automatic Module Names, que seria criado a partir do nome do arquivo quando não houvesse uma especificação no module-info.class dentro de um JAR. Uma vez que não é possível ter qualquer garantia em relação aos nomes de arquivos, essa questão parece ter causado um desconforto na comunidade Java preocupada com questões relacionadas à compatibilidade de aplicações existentes. Stephen Colebourne, autor do Joda Time e da package time do Java 8, escreveu:
"Os módulos automáticos permitem que módulos dependam de outras coisas que não somente módulos. No entanto, para se conseguir isso é necessário especificar o nome de um arquivo, e não o nome do módulo. Ter um módulo que dependa de um nome de arquivo poderá trazer dificuldades no futuro. Uma nova informação no MANIFEST.MF permite que qualquer projeto open source escolha um nome para seu módulo e publique essa escolha imediatamente. Assim que o JPMS visualizar essa informação no MANIFEST.MF, vai utilizar esse valor como o nome para o módulo automático.
Os membros da Comunidade devem evitar ao máximo a publicação de arquivos JAR que dependam de nomes de arquivo. Porém, os membros da Comunidade poderão publicar arquivos JAR com uma nova informação no MANIFEST.MF a partir da incorporação dessa JSR (ainda que, tecnicamente, essa feature ainda não esteja disponível, devendo ser finalizada em breve)."
As críticas em torno do Automatic Module Names já tinham sido discutidas na lista de emails do Expert Group e a especificação foi publicada para análise na esperança de que seria aprovada da forma que estava descrita.
Mark Reinhold reconheceu tais problemas relacionados ao Automatic Module Names, chegando a liderar uma revisão dessa questão no grupo de emails. No entanto, essa revisão não foi incluída na versão submetida para análise do Comitê Executivo do JCP. Após acompanhar as discussões em torno do assunto, alguns membros do comitê disseram não poder votar a favor da aprovação da especificação, uma vez que a mesma não incluia as discussões mais recentes, ocorridas na lista de emails:
"A London Java Community está votando "Não" para a especificação na forma que ela foi submetida no início do período da votação. Durante os 14 dias de votação, grandes avanços foram feitos pelo líder da especificação e o Comitê Executivo pôde chegar a um consenso em questões bastante delicadas como o #AutomaticModuleNames.
O que nos deixa [SAP SE] especialmente preocupados é a falta de comunicação direta com o Expert Group. Uma vez que havia grande expectativa de que a especificação não seria aprovada por ⅔ dos integrantes, nós esperávamos a utilização dos 30 dias adicionais para as reuniões entre os especialistas e líder da especificação, com a intenção de discutir as questões ainda pendentes e posterior apresentação de uma nova proposta mais sustentável. Mesmo sabendo que não é possível resolver todas as preocupações, nós achamos que os últimos dias demonstraram claramente como boas soluções são possíveis, como no caso das questões em torno do Automatic Module Names, e nós estamos certos de que um tempo adicional poderia ser utilizado para se apresentar uma melhor especificação para reconsideração dos votos."
Com menos de ⅔ dos votos, o período para aprovação da especificação se estende por mais 30 dias, antes da apresentação de uma nova proposta. Os novos votos poderão ser reavaliados com base na revisão de novas discussões provenientes do grupo de emails , como as questões em torno do Automatic Module Naming Scheme. Essa discussão, porém, trouxe à tona o fato de que novos debates devem ser feitos no grupo de emails e não em posts em blogs:
"Por fim, pedimos a todos os membros do comitê e ao líder da especificação que tragam novamente o assunto à tona, e comuniquem-se de uma forma direta e amigável, ao invés de provocar o outro em blogs ou demais publicações!"
Apesar de muitas pessoas interpretarem os votos no "Não" como votos contra o JPMS, a realidade é que essa JSR ainda é um trabalho em desenvolvimento e tem uma série de questões delicadas a serem resolvidas antes de ir para uma votação final. A nova votação pelo Comitê Executivo do JCP acontecerá novamente em cerca de 30 dias, e talvez essa nova votação encontre outras questões que ainda não foram discutidas.
No entanto, uma vez que uma JSR passe por uma votação pública, ela entra em um novo ciclo de revisão que não pode ser repetido. Ainda que isso não afete a implementação do OpenJDK, onde o código já está disponível, a decisão afetará outros provedores do Java que precisarão estar de acordo com as novas especificações. Para a Oracle, a alternativa seria ignorar o JCP, como um meio de trabalhar com uma especificação inacabada.
Martijn Verburg publicou no London Java Community Blog, explicando porque a LJC votou não:
"É por isso que o JCP existe (não, não é por questões políticas apenas).
Alguns eventuais observadores e parte da imprensa técnica certamente chegarão a conclusão de que tudo isso é apenas uma questão política entre grandes empresas. Alguns blogs e publicações públicas alimentaram essa sensação recentemente, mas nós pedimos para que as pessoas leiam os comentários que acompanham os votos "Não".
Apesar da Oracle estar à frente do Java, o Comitê Executivo do JCP existe para atuar como um guia para o ecossistema Java, e nós acreditamos fortemente que isso está funcionando como o previsto nesse caso."
Ben Evans, outro representante da London Java Community no Comitê Executivo disse ao InfoQ:
"A LJC tem apoiado o Jigsaw desde sua concepção. Nós estamos cientes da complexidade envolvida nessas questões fundamentais em torno de como as aplicações Java são empacotadas e deployadas. Isso torna a situação ainda mais crítica para que tenhamos o sistema de módulos correto desde a sua concepção.
Nas últimas semanas, especialmente após a submissão da JPMS JSR para revisão, o Expert Group teve grandes progressos ao resolver algumas questões. Mas algumas questões críticas ainda existem e precisam ser solucionadas antes de uma disponibilização para todos. A questão mais importante é a proposta para solução do Automatic Modules, como nossa comunidade indicou estar primariamente interessada na migração dos paths para módulos. Especialmente, por exemplo, para aplicações em Maven.
Pensando em outras questões, seria possível realizar alguns hackdays e analisar como a comunidade reagiria a essas novas funcionalidades propostas, uma vez que o Expert Group já apresentou alguns guias de como as novas funcionalidades deveria ser aplicadas em códigos já existentes.
JPMS ainda tem um grande potencial, mas ainda é preciso trabalho antes de se considerar a especificação pronta para uso de todos."
Time Ellison, da IBM, publicou um post comentando seu voto e relatando um desejo de que as questões pendentes sejam resolvidas:
"Nós continuamos otimistas que o Expert Group e o Líder da Especificação continuarão a trabalhar juntos no aprimoramento da especificação, de uma forma bastante próxima e produtiva. Estamos confiantes de que a JSR 376 pode ser aperfeiçoada para melhorar diversas questões pendentes e ser apresentada de uma forma que não traga impactos significativos para a agenda do Java 9."
O InfoQ está tentando entrar em contato com Mark Reinhold para ouvir seus comentários e publicará suas opiniões assim que obtiver novas informações.