Em um post intitulado Repensando o JDK7 (publicado também no jdk7-dev), Mark Reinhold apresenta uma sugestão de que certos elementos previstos pelo JDK7 sejam suspenso até o JDK8 para que o lançamento seja antecipado ao invés de atrasado. A sugestão causou diversas discussões pra saber se isso seria boa ou má idéia. E foi discutido no InfoQ Brasil. Admitindo que os atrasos do JDK causaram a falha do cronograma anunciado (que provavelmente nunca seria atingido de qualquer forma), a discussão atual centra-se entre lançar uma versão antecipadamente com o que já é suportado ou esperar até que tudo esteja pronto. Mark sugere que:
Nossa estimativa atual para este "Plano B" é que poderíamos lançar um JDK 7 reduzido em meados de 2011 e o JDK 8 no segundo semestre de 2012. Para resumir:
- Plano A: JDK 7 (como atualmente definido) em meados de 2012
- Plano B: JDK 7 (menos Lambda, Jigsaw, e parte do Coin) em meados de 2011
- Plano B: JDK 8 (Lambda, Jigsaw, o resto do Coin) no final de 2012
Ironicamente, o blog do Mark tem o subtítulo "Não há um momento a perder!", mas como vários comentários do post dizem, é melhor lançar antecipada e frequentemente que nunca lançar. Embora haja alguns recursos muito desejados (e alguns menos desejados) no conjunto de recursos do Plano B, não há dúvida de que parte do Projeto Coin será benéfico para a linguagem Java. Tais recursos foram esclarecidas por Joseph D. Darcy:
- literais binários e sublinhados em literais
- strings no switch
- operador diamante
- Melhorias na manipulação de exceções
- Invocação simplificada de varargs
- try com resources
O Plano B também inclui classes da jsr166 (ForkJoin, TransferQueue, Phaser). Além disso, outras melhorias estarão presentes na JVM, incluindo JSR292 (suporte à invokedynamic). Embora isso possa parecer ter pouco uso para linguagens estaticamente tipadas como Java, pode ser útil para otimizações onde o Method.invoke() é atualmente utilizado (por exemplo no RMI ou outras aplicações em servidores corporativos).
Se o suporte à literais MethodHandle também for incluído, será muito mais fácil usar métodos dentro de uma classe java sem precisar de reflection para encontrar a mensagem com o nome certo. (literais MethodHandle usam o invokedynamic debaixo dos panos, mas requerem uma alteração à especificação da linguagem java (JLS), de modo que seja possível que o Plano B inclua a instrução invokedynamic da VM e a classe MethodHandle, mas não suporte ao literal).
Quem está implementando linguagens alternativas sobre a JVM está animado com a mudança de calendário, uma vez que invokedynamic ficará utilizável mais rapidamente do que se tudo fosse adiado até 2012. (Em todo caso, note que em ambos os planos a chegada de Lambdas e companhia não será antes de 2012.) Charles Nutter, que está trabalhando tanto em JRuby como em Mirah sobre JVM, é imparcial sobre as mudanças
:
Os method handles provavelmente são a mudança mais importante por vir no JDK 7 para o meu trabalho. Eles certamente se tornarão parte chave de todas as linguagens da JVM que desejam representar funções ou ponteiros de função sem a sobrecarga associada com a geração de classe de um único método (como praticamente todas as linguagens da JVM atual são forçadas a fazer num lugar ou outro).
Mas o longo atraso em disponiblizá-los significa que implementações de linguagens como JRuby ficam na pior, construindo estratégias de geração de código para evitar a explosão do permgen (ou apenas para evitar consumo excessivo de memória). Quanto antes conseguirmos colocá-los num release, melhor. Eu estaria disposto a abrir mão do Jigsaw, Lambda e Coin? Jigsaw e Coin talvez, apesar de que fariam falta. Sobre lambda... se não puder ser feito direito no curto prazo, com um tipo verdadeiro para funções, integração com method handles e invokedynamic, então deveria ser atrasado até que possa ser feito corretamente.
É doloroso dizer isso, mas temos outras linguagens na JVM que podem fazer closures agora, incluindo meus próprios JRuby e Mirah (que, incidentalmente, fornece closures e mais sem *nenhuma* biblioteca ou suporte da JVM) e, para nós "programadores de sistemas" da JVM, classes internas anônimas ainda são muito boas. (Veja os fontes do JRuby, usamos centenas delas). Ah, e para o pessoal do Scala... por favor me expliquem como Scala resolve qualquer uma das funcionalidades ausentes que o plano B omite.
Sim, Scala tem closures, mas estes geralmente não são compatíveis com outras linguagens ou com código java comum (a não ser que você limite seu projeto consideravelmente), o que os tornam inúteis para todo mundo que não seja desenvolvedor Scala. Não há nada para endereçar os objetivos do Jigsaw. E a maior parte do Coin que Scala já fornece estão prontos para uso (acredito eu). Porém Scala não é um substituto ao java como linguagem universal da JVM, e nunca será.
Outros dizem que releases rápidos e frequentes poderiam ser feitos ainda mais frequentemente. Apesar do Java 6 estar conosco há tempo, o esquema de versionamento esconde algumas mudanças importantes que a VM sofreu neste período. Osvaldo Pinali Doerdelein escreveu:
O motivo é claramente o JDK 6. Eu tenho monitorado constantemente os releases pós-6uN, os quais a Sun/Oracle continua a expandir o quanto pode sem violar o próprio TCK. Eu já estou testando a primeira compilação do 6u23 que, além de correções no Swing, trazem atualizações significativas pra VM, incluindo a novíssima HotSpot 19 (a mais atual do JDK 7 até o momento).
Inclui também funcionalidades avançadas do JDK 7, como o coletor de lixo G1, suporte completo para a JSR 292 e outros itens, tais como CompressedOops com heaps de 64Gb, correções de CMS e toneladas de correções menores e melhorias na VM e no runtime. Numeros de versão são uma coisa meio arbitrária.
A Sun mudou o esquema de versionamento do J2SE / Java SE algumas vezes, pro desgosto de meio mundo. Algumas pessoas pensam que 6u10 deveria ser chamado 6.1. Neste caso, eu renomearia 6u14 -> 6.2, 6u18 -> 6.3, 6u21 -> 6.4 e 6u23 para 6.5. Talvez me sentisse melhor: "É, o JDK 7 atrasou, ruim... mas pelo menos estamos recebendo o 6.5! "
A outra vantagem do atraso é que ele permite que as coisas sejam feitas corretamente, ao invés de apressadas. Existem objetivos conflitantes no projeto Lambda e em bibliotecas fundamentais que provavelmente causariam problemas no curto prazo (por exemplo: como atualizar as Collections num curto período para que se beneficiem de lambdas?). Ao conseguir mais tempo para o projeto Lambda, o projeto pode ser harmonizado à tempo para o JDK 8 sem segurar o JDK 7. Além disso, a última proposta elimina completamente os function types (abordado anteriormente no infoQ).
Houve uma convocação para rever a decisão considerando que haveria mais tempo. Entretanto, assim como não era claro porquê eles tinham sido removidos inicialmente (problemas com o sistema de tipos ou falta de tempo), não é claro se eles voltarão. O mesmo também pode ser dito sobre o Jigsaw, a tentativa do JDK para um sistema de módulos. Enquanto o OSGi é há tempos o sistema de módulos padrão para Java, o Jigsaw tentou re-inventar a roda no particionamento das bibliotecas java. O Qwylt existe como uma maneira de unificar os dois, mas como foi observado, a JVM e as bibliotecas Java servem dois propósitos diferentes e um plano C para separar a JVM das bibliotecas seria uma grande vantagem para todos. Dessa maneira, as bibliotecas (como IO, NIO, NNIO, NNNIO) poderiam evoluir em seu próprio ritmo ao invés de depender de um release particular da combinação de bibliotecas da JVM. Peter Kriens escreveu
:
O Java está sendo lentamente prejudicado pelo engano de que quanto maior fica a plataforma, melhor. Entretanto, maior significa mais dependências internas e estas dependências tendem a aumentar a complexidade da palataforma rapidamente. Quanto mais corda tem, mais enrolado fica. Cronogramas atrasados repetidamente é um dos sintomas disso. Modularidade é o único mecanismo que nos permite ter o melhor dos mundos.
Se java possuísse uma plataforma central, poderíamos facilmente incluir novas implementações de JSRs como módulos isolados. eu nunca uso Swing, então porque tê-lo na minha plataforma? E talvez eu precise de outra versão se usá-lo. Modularizar os JSRs complicaria a vida de aplicações triviais, mas para qualquer aplicação real, gerenciar dependências já é parte de uma vida complicada. Complicada porque surpreendentemente o java não fornece nenhum suporte para manipulação destas dependências.
O que precisamos é de uma plataforma minimalista, mas que incorpore verdadeira modularidade. Ao invés de incluir todos pacotes javax, esse java mínimo deveria incluir apenas pacotes centrais bem definidos e um mecanismo para manipulação de módulos a partir de repositórios (remotos) que facilitassem a inclusão de bibliotecas e aplicações nos desktops e servidores.
Perl o faz, Ruby o faz, Python o faz, porque o Java tem tanta dificuldade em fazer a mesma coisa? Não deveria cumprir sua promessa e fazê-lo melhor? Temos a tecnologia, todas as partes estão lá. Por favor Oracle, este atraso oferece uma oportunidade, poderíamos tornar o java ágil novamente?
Com este breve anúncio de que a oracle está considerando atrasar partes das funcionalidades planejadas para o JDK 7, eles transformaram um problema em uma disputa. O volume de comentários encorajando a abordagem de releases curtos e frequentes os dá suporte para anunciar o atraso formalmente no JavaOne e reivindicar que a comunidade os apoia. (Se houvessem anunciado apenas na lista lambda-dev, eles teriam uma proporcao muito maior de resposta negativas e menor de positivas).
Isso também traz a esperança de que a plataforma java terá tempo para amadurecer as bibliotecas que ainda não estão prontas (lambda) e ponderar quais são necessárias (jigsaw). Uma coisa é certa: ao abrir o problema ao público, a Oracle finalmente entendeu o valor da opinião da comunidade.