Durante a Devoxx Mark Reinhold, Chief Engineer para Java SE, deu uma apresentação sobre as últimas direções do Java 7, que estima-se o lançamento no início de 2010. Embora Mark descreveu sua apresentação como provisória e não concluída, houveram muitas reações da comunidade, especialmente sobre a omissão de Closures.
Hamlet D'Arcy que esteve em Devoxx, publicou um resumo da apresentação do Mark sobre as funcionalidades do Java 7. Algumas das mudanças mais importantes listadas são:
Modularização - 294 e o projeto Jigsaw
292 - JVM Suporte para linguagens dinâmicas
JSR 203 – Mais API`s novas de E/S (I/O) que as quais estão próxima de concluídas, incluindo verdadeiro E/S assíncrono e finalmente uma API de sistema de arquivos real
JSR TBD (to be done, para ser feita): Pequenas mudanças na linguagem (como segue)
Relançamento Seguro – Permite uma cláusula catch mais ampla, com um compilador mais esperto sobre o que você pode relançar baseado no que foi lançado no bloco try. (Eu não havia percebido isso antes mas parece ser legal)
Expressões de de-referência de nulo – Checagem de nulos com a sintaxe ‘?’ parecido com Groovy…permitindo aos desenvolvedores se livrarem da checagem de nulos aninhadas.
Melhor inferência de tipos – Exemplo voltado a instanciações genéricas, mas não ficou muito claro como as inferências seriam (melhores na minha opinião).
Multi-catch - (sim!) permite um lista separada por vírgula de distintos tipos de exceções na cláusula catch.
Joe Darcy está liderando os esforços do Open JDK e seu blog foi referenciado: http://blogs.sun.com/darcy
JSR 296 - Swing application framework – Ainda necessita ser algo fácil criar aplicações Swing.
A porta aberta das funcionalidades do 6u10 (Java Kernel, Quickstarter, New Plug-in, etc.)
Ele também menciona muitas características que foram consideradas para o Java, porém provavelmente não serão parte da versão 7:
Closures – Nenhum consenso sobre uma proposta.
Reified generics – (Acesso aos tipos genéricos em tempo de execução)
Propriedades de primeira classe.
Sobrecarga de operadores
Sintaxe para BigDecimal
JSR 295 - Beans Binding
No Java.net existe uma discussão sobre “Por que estes foram removidos do Java 7 quando eram os que você mais estava interessado” e no momento da escrita desta notícia Closures estão a frente de todas as outras funcionalidades:
Closures 47.4% (734 Votos) Reified generics 17.2% (266 Votos) Propriedades de primeira classe 10.4% (162 Votos) Sobrecarga de operadores 4.3% (67 Votos) Sintaxe para BigDecimal 3.4% (54 Votos) JSR-295 Beans Binding 7.3% (113 Votos) Eu não estou interessado em nada disso 9.7% (150 votos)
Ricky Clarkson acredita que sem Closures Java está “morto”:
Se isso for confirmado. Esqueça a vontade de James Gosling por Closures, esqueça 3 funcionais protótipos de compiladores com Closures, esqueça todas as outras linguagens da JVM com suporte a Closures, Java 7 não terá Closures..
Martin Kneissl também sente que Java 7 sem Closures é uma má notícia:
Java deveria ter ganho Closures no lugar do novo estilo de laço "for" adicionado no Java 5. Ele deveria ter ganho Closures no Java 6. Agora parece que não ganhará Closures no Java 7.
Closures não são difíceis de entender. Ao menos quando você as compara com classes internas anônimas do Java. Alguns não concordam. Eu não concordo com o raciocínio dos que se opõem a Closures quando eles alegam que existem muitos programadores Java estúpidos por aí e você precisa limitar as possibilidades da Linguagem para preveni-los de causar muitos danos. Isso é simplesmente impossível. Programadores incompetentes irão atirar no próprio pé em qualquer linguagem.
Felizmente existem outras linguagens na JVM em que se pode usar a real força do Java: bibliotecas, portabilidade, e (até certo ponto) ferramental.
Dustin Marx, é um pouco mais ambivalente sobre Closures no seu post sobre as funcionalidades que mais fazem falta no Java 7:
Assim como essa notícia, existem mais de 160 votos (mas novos votos estão entrando regularmente e rapidamente agora mesmo) e de longe o líder para a mais sentida e descartada falta do Java SE 7 são closures. Neste ponto, a funcionalidade Closures havia recebido relativamente algo próximo do total de votos. Com todo respeito, mas isso era esperado. Closures parece dominar as discussões do Java SE 7 até ser anunciado que não seria implementado no Java SE 7. Entretanto, uma das razões para essa significante discussão é a controvérsia em torno do conceito de ter Closures como um todo e também em como Closures devem ser implementados.
Enquanto closures tem sido uma das propostas mais calorosamente discutidas do Java SE 7, fui pessoalmente relativamente ambivalente sobre isso. Eu posso ver como isso seria ocasionalmente útil no meu trabalho, mas eu consigo viver sem na maior parte do tempo. Em outras palavras, eu me não me lembraria se fosse adicionado, mas realmente não me incomodou quando ouvi que não seria adicionado no Java 7. Entretanto, se nós acreditarmos nos resultados desta discussão, mais da metade dos desenvolvedores desejam essa funcionalidade mais que todas. Isso corresponde a uma pergunta de uma pesquisa do Java.net sobre desenvolvedores querendo a questão sobre closures resolvidas a tempo para Java SE 7.
Osvaldo Doederlein está animado sobre as novas funcionalidades, mas ainda sente a falta de Closures:
Java7 será o melhor lançamento em muitos anos com uma sábia infra-estrutura: 294/Jigsaw; 294/Jigsaw; Classloading concorrentes – Eu penso que isso pode aumentar o tempo de boot de aplicações grandes, especialmente baseadas em microkernel como servidores JavaEE e IDEs; XRender – finalmente farão cidadãos Java de primeira classe para aplicações desktop Linux; G1; Suporte completo a 64 bit (irá estrear atualmente no 6u12, baixe o beta); ForkJoin.
Tanta coisa boa, eu praticamente consigo esquecer sobre a tristeza de provavelmente não ter Closures. Eu imagino que é tempo para migrar para Scala, JavaFX ou outra qualquer linguagem moderna da JVM (não somente lixos dinamicamente tipados como Ruby ou Python). Eu acho que já faz cinco anos até agora que apenas escrevo código Java padrão e se escrevo código de baixo-nível é para algum pequeno trabalho (middlewares etc). Obrigado ao conservadorismo da comunidade, a linguagem Java é lenta para se ir do perfil legado ao de baixo-nível.
Em contra-partida Matt Grommes foca na sintaxe para BigDecimal:
Eu venho trabalhando com sistemas financeiros há um ano e a sintaxe para BigDecimal é insanamente amedronte. Estou realmente nem um pouco feliz sobre isso.
Stephen Colebourneapresentou ao público da Devoxx e JavaEdge com 10 possíveis mudanças na linguagem para o JDK7 e pediu a eles que votassem:
emos um claro vencedor – tratamento de nulos. Tratamento de nulo tevê 50 primeiros votos de preferência, o dobro do segundo lugar string switch e quase um terço de todas primeiras preferências. Essa tendência continuou com pelo menos dois terços que o colocaram entre suas quatro mudanças preferidas.
Outras opções populares foram String Switch, Multi-catch de exceções, laço “for-each” melhorado para Map’s, laço “for-each” melhorado que permita remover ou encontrar o índice corrente e gerenciamento de recursos no estilo ARM.
Opções não tanto populares (especialmente considerando os péssimos valores de ‘má idéia’) foram acesso a List/Map usando [] e interpolação de String (strings com ${variável}).
Inferência a tipos genéricos e string de múltiplas linhas foram considerados de relativa baixa importância mas não necessariamente questionáveis.
Deve ser notado que em Devoxx os votos em Closures foram divididos em 50/50.
Você pode encontrar mais informações sobre a próxima geração do Java SE bem aqui na InfoQ.