Novo roadmap Java 7: aparentemente não vai ter closures

É 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.

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.

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?

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…

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.

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.

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.

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?

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:

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?

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.

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.

thingol:

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?

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.

Pequena correção. A DLR não exige nenhuma modificação na CLR, é uma biblioteca sem nada de especial.

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.

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.

"

eu não estou acreditando

Um fork para mim seria a melhor opção tecnicamente falando. O problema é que gerentes de projetos que não entendem nada de programação vão sentir medo de que a versão do java retrocompatível com suas aplicações não seja atualizada. Sei que isso não tem nada a ver, não vai ter problema algum, mas sabe como são esses gerentes. Já ouví cada coisa…

Acho que o pessoal se esqueceu que Java é o Cobol da primeira década do século 21 (que está por terminar, por sinal).

E é por isso que a retrocompatibilidade tem de ser mantida a qualquer custo, e é por isso que as alterações propostas na linguagem são meio desajeitadas (como a proposta BGGA de closures), mas em suma não quebram de forma nenhuma a retrocompatibilidade.

Você pode quebrar a retrocompatibilidade com coisas aparentemente bem estúpidas, como incluir uma nova palavra-chave (quantos de vocês não tiveram problema com a nova palavra chave “enum”? É muito comum em programas antigos escrever algo como:

Enumeration enum = ....

Mas as alterações propostas não quebram, porque não há modo de escrever um programa no Java 1.4 que seja entendido de outra maneira pelo Java 8.0 (por exemplo).

Em quê você não está acreditando? Que não vai ter closures? Que tem gente sugerindo um fork? Que tem gente querendo quebrar a retrocompatibilidade?

Por sinal, um dia desses no começo do ano passado, eu cheguei a conversar com um amigo sobre a possibilidade de fazer um fork do java (e chamá-lo de sumatra, borneo ou sulawesi). Mas acabamos concluindo que seria mais viável criar uma outra linguagem nova, pois para valer a pena a quantidade de mudanças seria enorme.

Edit: Por sinal, de acordo com a nova ortografia, o certo é retrocompatibilidade ou retro-compatibilidade?

Que tal chamar de Krakatoa (um vulcão próximo a Java que explodiu em 1883), já que é para quebrar a compatibilidade?

victorwss:

Edit: Por sinal, de acordo com a nova ortografia, o certo é retrocompatibilidade ou retro-compatibilidade?

Je ne sais pas - na cartilha do Estadão se diz para aguardar o Vocabulário Oficial que será publicado em fevereiro.

Sim, exatamente isso, só que um detalhe que tbm é verídico, essas empresas que rodam suas aplicações em Java 1.3, e aqui no Brasil por exemplo tem muitas, não mudaram até hoje não vão mudar seus aplicativos para Java 5 ou 6, então um “novo” Java em 2010 (o que não vai acontecer) não traria esse problemas pra eles, afinal eles ainda rodam uma JVM 1.3.

O fato é que adicionar gambiarras na linguagem não ajuda em nada, acho que pioria na verdade, como já disseram, Java hoje esta cheia de retalhos, se não tiver um ponto de “Stop the Line” será assim eternamente? uma linguagem que tenta evoluir em cima de retalhos e gambiarras? Por que não usar uma “nova” linguagem mais moderna então?

Se a intenção é ter Java só como plataforma mesmo, então tanto faz o qeu fizerem com a linguagem, vamos programar em outras coisas mesmo e só jogar em cima da VM depois.

[]s

Tb acho que usar outras linguagens em cima da VM é uma boa opção para o problema e tb não deixa de ser um fork. :lol:

Segundo a nova ortografia, quando a primeira palavra termina com vogal, e a segunda começa com a mesma vogal, usa-se hífen

?

Analisando o resto da especificação (veja o PDF mencionado acima) , então não é para usar o hífen, e portanto o correto é “retrocompatibilidade”

falando em closures pra java, como voces imaginam que seria a sintaxe??
no ruby por exemplo temos coisas como

String.methods.sort.each{ |s| puts e.upcase if e.is_a? Integer }

logicamente que isso não vai imprimir nada pos a String não possui metodos do tipo inteiro mas a questão é, como seria algo assim em java?

ou como em um outro exemplo

def confere
c = 0
lambda{ c += 1 }
end

10.times{ puts confere.call }

ou

imprime_numero_atual = confere
10.times{ puts imprime_numero_atual.call }

desculpem mas ta meio dificil imaginar como seria uma programação assim no java, o que voces acham?

att,

http://www.javac.info - (especificação e protótipo)
Tutorial em http://tronicek.blogspot.com/

todas as coisas que você mencionou.

1. closures estou surpreso por não ter ingressado, e ainda não consegui entender porque não a teremos no mustang.

2. quanto ao fork, acho um desastre e pelo pouco que vi não achei boas vantagens, a não ser que me provem o contrário. Pelo ponto de vista de utilizar o compartilhamento de instâncias, se uma cair todas cairão, então qual é a graça afinal ? Como se resolve este problema, acaba-se criando outros ?

ps: até acho interessante múltiplas threads para cada projeto, mas qual a principal aplicação disto ? o pessoal se revoltou com o garbage collection ? esse pessoal parece ter sofrido alguns problemas de escalabilidade resolvidos na tora pelos arquitetos do eBay

Veja: http://www.guj.com.br/posts/list/99477.java

Eu sinceramente acharia que Method Delegates são uma feature muito legal que falicitaria a inclusao de closures…