Notícia publicada no site da InfoQ:
Novo roadmap da tecnologia Java 7 publicado, onde closures ficou de fora.
Será possível que, depois de tanta discussão e 3 protótipos, ainda não teremos esse recurso no Java 7?
É triste, espero que seja apenas uma forma de feedback retroativo volátil.
Será que esses “novos planos” têm alguma relação com a redução do quadro de funcionários, queda na bolsa, etc… já anunciada da SUN?
Ou melhor, será que não tem alguma coisa haver com a “tão falada” crise?
Closures e reificação (que são os mais importantes) acabaram de fora, uma pena.
Pelo menos o multi-catch e a inferência de generics nós teremos. Mas isso são coisas que na verdade só resolvem problemas menores que apenas incomodam um pouco e no fim não fazem muita falta. Closures e reificação eram a grande falta relativas a verdadeiras falhas na linguagem, que decerto vão fazer falta.
Edit: Se bem que o java atualmente já é uma colcha de retalhos e já tem uma estrutura bem inchada e torta por causa de problemas e gambiarras introduzidas em versões anteriores que não podem ser eliminadas por conta da retro-compatibilidade. E nesse aspecto, closures só iria piorar a situação.
Talvez closures só entrem com a alteração da JVM que dá suporte a method handles, muito necessária para linguagens que rodam na JVM que não são Java, tais como JRuby ou Scala.
A implementação da proposta BGGA de Closures do Neal Gafter (que usa a JVM padrão) ficou um pouco desajeitada sem esse novo recurso (“method handles”), que talvez entre no Java 8.
O Rémi Forax (method handles == closures ??) tentou usar method handles para implementar closures e aparentemente ficou bem mais claro e sem usar um monte de classes intermediárias, criadas pelo compilador.
[quote=victorwss]Closures e reificação (que são os mais importantes) acabaram de fora, uma pena.
Pelo menos o multi-catch e a inferência de generics nós teremos. Mas isso são coisas que na verdade só resolvem problemas menores que apenas incomodam um pouco e no fim não fazem muita falta. Closures e reificação eram a grande falta relativas a verdadeiras falhas na linguagem, que decerto vão fazer falta.
Edit: Se bem que o java atualmente já é uma colcha de retalhos e já tem uma estrutura bem inchada e torta por causa de problemas e gambiarras introduzidas em versões anteriores que não podem ser eliminadas por conta da retro-compatibilidade. E nesse aspecto, closures só iria piorar a situação.[/quote]
Acho que está na hora de quebrar algumas compatibilidades…
Sou contra quebrar a compatibilidade… Apesar de todos os problemas já citados. a retrocompatibilidade é uma das melhores coisas da linguagem, conseguimos utilizar sistemas em versões anteriores sem nenhuma modificação no código ou recompilação.
Muitas pessoas acreditam que a melhor saída para utilizar closures sem “quebrar” a linguagem seja a VM suportar mais de uma linguagem, acredito que essa seja a melhor saída…
Mas a sintaxe BGGA de closures é bastante desajeitada, justamente para não quebrar a compatibilidade (afinal de contas, foi designada pelos mesmos caras que inventaram o Generics do Java, um recurso que é desajeitado justamente para não quebrar a compatibilidade). Se quisessem quebrar compatibilidade a sintaxe de closures seria bem mais simples e as closures poderiam, entre outras coisas, eliminar uma boa parte das “anonymous classes” que são necessárias para implementar os famigerados “listeners”.
O problema é que, justamente para não quebrar a compatibilidade, a implementação (e não somente a sintaxe) ficou bastante desajeitada.
Esses method handles são como os delegates de C#, um tipo de ponteiro de função?
O plano original era usar as versões ímpares para colocar recursos novos, e deixar as versões pares para deixar a poeira assentar, só adicionando bibliotecas e refinando a JVM. Isso já mudou, ou significa que uma possível implementação de closures não sai antes do Java 9?
[quote=ignacio83]Sou contra quebrar a compatibilidade… Apesar de todos os problemas já citados. a retrocompatibilidade é uma das melhores coisas da linguagem, conseguimos utilizar sistemas em versões anteriores sem nenhuma modificação no código ou recompilação.
Muitas pessoas acreditam que a melhor saída para utilizar closures sem “quebrar” a linguagem seja a VM suportar mais de uma linguagem, acredito que essa seja a melhor saída…[/quote]
java 5 quebrou compatibilidade,
Sou a favor de manter a compatibilidade, mas chega uma hora que não da mais né.
Assim como a maioria aqui, adoraria ver a introdução de closures em Java…
Contudo, uma das coisas que me fizeram amar Java desde os primórdios é justamente a “vilã” retro-compatibilidade.
Sinceramente, não sei o que pensar.
Java conseguiu muitos adeptos sem vários “recursos legais” como esse.
Acredito que a quantidade de programadores diminuirá menos se a retro-compatibilidade for mantida.
Eu poderia deixar Java ou passar a programas em outra linguagem (adicionalmente) para aproveitar estes “recursos legais”.
Mas a chance de eu abandonar a linguagem de vez não é grande.
Agora, se implementarem os “recursos legais” e as minhas aplicações começarem a ter problemas para funcionar, posso acabar mudando de linguagem.
Pelo simples fato de que, já que vou ter que mexer drásticamente na aplicação, posso querer aproveitar pra “mudar de ares” ou usar uma linguagem que se apresente melhor pro problema original…
Enfim… Não acho que minhas justificativas estão muito boas e nem quero gerar discussões sobre elas…
Quero apenas reforçar a importância da adição de funcionalidades como closures em Java sem que sejam quebrados os atuais benefícios da linguagem.
Forte abraço a todos.
[quote=lgi2020]Assim como a maioria aqui, adoraria ver a introdução de closures em Java…
Contudo, uma das coisas que me fizeram amar Java desde os primórdios é justamente a “vilã” retro-compatibilidade.
Sinceramente, não sei o que pensar.
Java conseguiu muitos adeptos sem vários “recursos legais” como esse.
Acredito que a quantidade de programadores diminuirá menos se a retro-compatibilidade for mantida.
Eu poderia deixar Java ou passar a programas em outra linguagem (adicionalmente) para aproveitar estes “recursos legais”.
Mas abandonar a chance de eu abandonar a linguagem de vez não é grande.
Agora, se implementarem os “recursos legais” e as minhas aplicações começarem a ter problemas para funcionar, posso acabar mudando de linguagem.
Pelo simples fato de que, já que vou ter que mexer drásticamente na aplicação, posso querer aproveitar pra “mudar de ares” ou usar uma linguagem que se apresente melhor pro problema original…
Enfim… Não acho que minhas justificativas estão muito boas e nem quero gerar discussões sobre elas…
Quero apenas reforçar a importância da adição de funcionalidades como closures em Java sem que sejam quebrados os atuais benefícios da linguagem.
Forte abraço a todos.
[/quote]
Concordo 100%, é muito bom falar que o Java de 5 ou 6 anos atrás funciona bem até hoje, só que mais rápido.
Ao contrário de outras plataformas que a quebra de compatibilidade faz parte do negócio pra vender novos softwares.
[quote=rubinelli]Esses method handles são como os delegates de C#, um tipo de ponteiro de função?
O plano original era usar as versões ímpares para colocar recursos novos, e deixar as versões pares para deixar a poeira assentar, só adicionando bibliotecas e refinando a JVM. Isso já mudou, ou significa que uma possível implementação de closures não sai antes do Java 9?[/quote]
Exatamente, e é por isso que o .NET (CLR) está um pouco adiantada em relação à JVM nesse aspecto (já que isso existe desde a versão 1 do Framework.) Mesmo assim, para suportar as novas linguagens do .NET Framework, está sendo modificada a CLR para ela ser mais dinâmica (procure por DLR).
O .NET Framework 3.5 tem verdadeiras “closures”, no sentido que se dá à palavra. Isso não existia antes, mas não foi necessário implementar nenhum recurso “cabeludo” na CLR porque já existiam delegates desde o começo.
[quote=thingol][quote=rubinelli]Esses method handles são como os delegates de C#, um tipo de ponteiro de função?
O plano original era usar as versões ímpares para colocar recursos novos, e deixar as versões pares para deixar a poeira assentar, só adicionando bibliotecas e refinando a JVM. Isso já mudou, ou significa que uma possível implementação de closures não sai antes do Java 9?[/quote]
Exatamente, e é por isso que o .NET (CLR) está um pouco adiantada em relação à JVM nesse aspecto (já que isso existe desde a versão 1 do Framework.) Mesmo assim, para suportar as novas linguagens do .NET Framework, está sendo modificada a CLR para ela ser mais dinâmica (procure por DLR).
O .NET Framework 3.5 tem verdadeiras “closures”, no sentido que se dá à palavra. Isso não existia antes, mas não foi necessário implementar nenhum recurso “cabeludo” na CLR porque já existiam delegates desde o começo.[/quote]
Concordo com o fato de que, em alguns pontos, o .NET está mais adiantado.
Mas meu grande problema com o .NET, assim como quase tudo da Microsoft, é que se tiver que quebrar compatibilidade com tudo e todos eles vão lá e fazem.
Isso muitas vezes significa refactoring, novas IDE, novas bibliotecas… Nao no sentido de melhorar… Mas no de fazer funcionar, já que, na maioria das vezes, pára muita coisa.
Deixo apenas registrado que acho bom o .NET evoluir.
A concorrência gera aperfeiçoamento.
E espero que Java seja um dos concorrentes que consiga se aperfeiçoar e evoluir.
[quote=thingol][quote=rubinelli]Esses method handles são como os delegates de C#, um tipo de ponteiro de função?
O plano original era usar as versões ímpares para colocar recursos novos, e deixar as versões pares para deixar a poeira assentar, só adicionando bibliotecas e refinando a JVM. Isso já mudou, ou significa que uma possível implementação de closures não sai antes do Java 9?[/quote]
Exatamente, e é por isso que o .NET (CLR) está um pouco adiantada em relação à JVM nesse aspecto (já que isso existe desde a versão 1 do Framework.) Mesmo assim, para suportar as novas linguagens do .NET Framework, está sendo modificada a CLR para ela ser mais dinâmica (procure por DLR).
O .NET Framework 3.5 tem verdadeiras “closures”, no sentido que se dá à palavra. Isso não existia antes, mas não foi necessário implementar nenhum recurso “cabeludo” na CLR porque já existiam delegates desde o começo.[/quote]
Pequena correção. A DLR não exige nenhuma modificação na CLR, é uma biblioteca sem nada de especial.
[quote=thingol]Talvez closures só entrem com a alteração da JVM que dá suporte a method handles, muito necessária para linguagens que rodam na JVM que não são Java, tais como JRuby ou Scala.
A implementação da proposta BGGA de Closures do Neal Gafter (que usa a JVM padrão) ficou um pouco desajeitada sem esse novo recurso (“method handles”), que talvez entre no Java 8.
O Rémi Forax (method handles == closures ??) tentou usar method handles para implementar closures e aparentemente ficou bem mais claro e sem usar um monte de classes intermediárias, criadas pelo compilador. [/quote]
Falou tudo…
é uma pena as closures não aparecer no roadmap… masss a esperança é a ultima que morre… :lol:
e outra, temos o Groovy!!!
abs
O problema é que a retro-compatibilidade tornou-se um peso muito grande para a evolução da linguagem. FORK JÁ! 
Não sei se o Java vai aguentar por muito tempo não quebrar essas compatibilidade, a linguagem já esta perdendo espaço para outras mais modernas, a ideia (agora sem acento rs) de fazer “gambiarras” só pra poder manter a compatibilidade com coisas com mais de 10 anos não me agrada, sei lá, talves comercialmente seja bom, mas em termos de “uso” acho que Java esta se afundando, falo isso pelo crescimento acelerado em projetos Ruby/Python nos último anos, e não vejo nenhum movimento de mercado que isso vá diminuir.
Java é a linguagem da base de piramide, estabilidade é fundamental. O esforco agora é fazer sua linguagem preferida (que provavelmente ja tem closures) integrar bem com java.
Fork já! ++
Se quiserem rodar aplicações antigas, usem o java 6. A JVM e a linguagem deveriam ser atualizadas já, isso iria gerar muitos benefícios e a possibilidade de linguagens dinâmicas rodarem bem melhor na plataforma. A sun deveria criar a nova grande revolução na plataforma, como foi o java 1.2.
"