victorwss wrote: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.

ignacio83 wrote: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...

lgi2020 wrote: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.

rubinelli wrote: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?

thingol wrote:

rubinelli wrote: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?

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.

thingol wrote:

rubinelli wrote: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?

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.

thingol wrote: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.