Inesperadamente o JDK 7 incorpora Closures "Simples", mas é adiado para o fim de 2010

Em sua apresentação na conferência de Devoxx, Mark Reinhold anunciou que o JDK 7 virá com "Closures". Com a inclusão desse recurso tão discutido, o lançamento do JDK 7 deverá ficar somente para Setembro de 2010.

Joseph D. Darcy, engenheiro chefe do Projeto Coin, que busca fazer pequenas alterações na linguagem para o Java 7, confirmou que a nova versão virá com uma pitada de Closures::

… JDK 7 virá com closures, algo a ser desenvolvido de closures menor que BGGA, e o prazo para lançamento do JDK 7 será estendido para algo em torno de Setembro de 2010.

Alex Miller quem citou que a Sun não apoiava closures mesmo com a criação de 3 propostas diferentes pela comunidade no passado:

Na verdade, não posso dizer o que fazer sobre aquilo. Durante anos a Sun insistiu que não há consenso em closures e atrasou a formação de um JSR ou grupo de especialistas no assunto mesmo com três propostas, em mãos, todas com protótipo.

Após o anuncio na Devoxx, Neal Gafter que era co-autor de uma das três propostas de Closures (BGGA, nome a partir das iniciais de Bracha, Gafter, Gosling e von der Ahé), liberou uma "proposta simplificada":

Mudanças nessa revisão

• A sintaxe de controle de chamada foi movida para uma especificação separada.
• O termo closure literal foi substituído pela expressão lambda.
• Nós melhoramos a sintaxe para expressões lambda, emprestando um pouco de Clang (um projeto de C/C++ melhorado). Agora há duas formas de expressões lambda: uma expressão lambda tem uma expressão controlada, enquanto uma declaração lambda tem uma declaração controlada.
• O termo closure object foi substituído por function object.
• O termo closure conversion foi substituído por conversão lambda, com um bloco de conversão separado para a sintaxe de controle de chamada.
• Adicionado novas semânticas para a declaração return: agora pode ser usado para retornar uma declaração lambda.
• java.lang.Unreachable renomeado para java.lang.Nothing ala Scala.
• Retirado suporte ao tipo null. A versão anterior usava null como uma alternativa para um tipo de exceção onde nada pode ser devolvido (thrown). O tipo Nothing veio para tal propósito.
• Melhora na restrição. Os conceitos de tipos de função restrito e irrestrito foram removidos. Agora, todas as expressões lambda são restritas. O equivalente da especificação anterior de closure irrestrito pode ser passado para um método utilizando a sintaxe de controle de chamada control invocation syntax.
• Adicionado suporte a referência de métodos: Adicionamos suporte para tratar referência à um método como função usando o recém introduzido #. A sintaxe é emprestada de referências-cruzadas do javadoc e da proposta de FCM.

Essa mudança repentina nos planos para o JDK 7 fez pessoas como Fabrizio Giudici opinar sobre o processo de decisão:

Não quero discutir se isso é uma coisa boa ou ruim (vocês sabem que eu acho isso ruim eu retirei qualquer julgamento já que entendo que a proposta não é BGGA nem CICE, mas algo novo). Eu estou chocado que após algumas semana a palavra final do Java 7 tenha sido dita com o Project Coin (o famoso final five or so), alguém mudou de ideia de repente. Que tipo de processo de decisão é esse?

Oh, entendí - a decisão vai ser no cara ou coroa, agora entendí de onde veio o nome do projeto. Temo que Java 7 possa se tornar a versão mais caótica de Java já liberada - uma ótima ideia se desejar matar isso antes da hora (já que não há muitas outras fontes de deterioração, como o acordo com a Oracle ou a discussão com a Jigsaw / OSGi).

Da mesma forma, Geertjan Wielenga pensa que a inclusão de Closures era um desenvolvimento bem inesperado:

Ótimas notícias e talvez melhores se ninguém questionasse tanto o por que o processo teve esse desfecho! Primeiro, temos todo um conjunto de propostas, que não surpreenderam logo de cara. E então, de repente, como um raio, temos "closures simples". (Fico imaginando se alguma das propostas existentes se chama "closures complexos". Simplicidade já não é a proposta inicial de closures?) OK, closures serão simples no sentido de não haver retornos externos (non-local return), sem controle de declaração, e sem acesso a variáveis que não estejam declaradas com final. De novo, como chegaram nesse consenso?

Cay Horstmann, disponibilizou diversos casos de uso para essa nova proposta BGGA, que é bem parecida com a proposta FCM:

Não sabemos na verdade o que a Sun pretende. Eu simplesmente analisei a proposta do BGGA 0.6a, que é presumidamente o que a BGGA é hoje. Ninguém falou que isso não parece muito com a FCM. Sem retornos externos. # para lambda. Desde que você precise anotar uma variável mutável com @Shared quando for capturar ela, entretanto as pessoas devem pensar duas vezes antes de sair escrevendo

    foreach(@Shared String v : values) 
        funcs.add( #() => v);

Como disse Alex Miller, a extensão do JDK pode fazer com que outros recursos entrem na release, como a biblioteca ParallelArray que fornece uma API funcional de estilo para mapeamento, filtro, reduzindo mais que um array de objetos Java:

Conversei um pouco com Bob Lee na QCon e ele acha que é possível que o adiamento do JDK 7 permita que o trabalho com o ParallelArray seja retomado e faça uso do novo suporte a closure.

Você pode encontrar maiores informações sobre Closures e JDK 7 aqui no InfoQ!