Afinal, haverá Closures no Java 7?

Quando todos achavam que não havia mais chances de closure entrar no java 7, eis que meu colega de trabalho Rafael Ferreira manda esse link:
http://puredanger.com/tech/2009/11/18/closures-after-all/

Essas notícias estão aparecendo no QCon de Sao Francisco e no Devoxx da Bélgica. Mark Reinhold criou rapidamente uma nova sintaxe, diferente das 3 outras propostas anteriormente:

Também parece que o Java 7 vai ser empurrado para o fim de 2010, criando um gap enorme de 4 anos entre o Java 6 e a nova versão, o recorde entre versões.

Olá

Pois é, muita demora. E closures virou um símbolo do quanto Java está ficando para trás. Mas não mudará o preço do dolar nem servirá tanto assim para o programador comum.

No link que já conhecia dos meus feeds qua atualmente leio a jato, há o seguinte comentário anônimo: Adding closures to Java is starting to sound like reforming health care!

O Java não está tão ruim quanto a gente acha. O problema é o tanto que a gente perdeu de saco envolvido com complexidades desnecessárias. Tenho até pena de quem dará manutenção no legado do Java. Estes sim terão que ganhar bem.

[]s
Luca

A demora entre a versão 6 e a versão 7 é mais ou menos (mas não oficialmente) justificável: a sequencia de demissões da Sun nesses últimos anos.

O problema das closures é que veio tarde demais. Fosse uma “feature” existente desde os primórdios, ela seria a base do JDBC, do Swing, das Collections, dos parsers de XML… se bobear no EJB… e sem falar em vários frameworks web que surgiriam e que seriam diferentes da atuais. Mas como vai só aparecer quinze anos depois do lançamento da linguagem Java, implica que closures será algo fora da realidade de qualquer framework; no máximo será opcional e torto.

Porém, é bom lembrar quo orientação a objetos não era muito famoso lá nos anos 90. E Java tinha que ser popular! Fazer uma linguagem com características bastante avançadas iria assustar muita gente.

pois é, a previsão seria para agora perto de março. 4 anos puxa!!!

vi pelo twitter de Jean-Laurent Morlhon, que é referenciado pelo link que paulo passou, logo no final, onde é mencionado a citação “lite” closure, alguém sabe do que se trata e como se exemplifica?

Mas vai entrar Extension methods?
Se não entrar, a utilidade de clousures vai ser bastante reduzida, pois não poderemos usar closures na API padrão do Java (Collections, IO, etc)!

Bom, enquanto o Java 7 não sai, vamos continuar usando Ruby/JRuby/Groovy/etc, que tem todos esses recursos “modernos” há anos :slight_smile:

po… que demora… final de 2010… de qualquer jeito me fica aquele pensamento que to me acostumando sobre a sun de “Antes tarde do que…mais tarde ainda” :frowning:

Eu não acredito mais em nada!! Só falta eles colocarem também aspectos nativos!!

Uma ajuda:
closure seria o que eu, carinhosamente, chamo de inner-function?
Nunca consegui enviar na cabeça o que é isso… sempre que vejo essa palavra fico em dúvida, dai consulto a wikipedia, e ela só reforça a minha idéia de inner-function

Definição de inner-function: objeto que, em tempo de compilação, pode ser tratado como um objeto qualquer, e que possui um ‘invoke’ implícito, que recebe n parâmetros.

Até lá já fiquei velho de esperar. Final de 2010?? Deve ser a última bolacha do pacote mesmo, senão nem compensa esperar por melhorias. Já existem muitas linguagens ae que fazem tudo isso que a sun quer implementar.

[quote=clone_zealot]Uma ajuda:
closure seria o que eu, carinhosamente, chamo de inner-function?
Nunca consegui enviar na cabeça o que é isso… sempre que vejo essa palavra fico em dúvida, dai consulto a wikipedia, e ela só reforça a minha idéia de inner-function

Definição de inner-function: objeto que, em tempo de compilação, pode ser tratado como um objeto qualquer, e que possui um ‘invoke’ implícito, que recebe n parâmetros.[/quote]

O que a propost tràs à mesa é mais que closures. É first class methods. Ou seja, trabalhar com métodos como sendo objetos. Básicamente isso já existe em java.reflect.Method. O que a proposta trás é uma forma simples de extrair uma referencia ao método sem usar reflection diretamente.

Se os métodos são cidadãos de primeira classe eles têm que ter literais. O literal de um método é a assinatura e o corpo.
Mas se ha um literal e ha um cidadão de primeira classe ha uma forma de declarar variáveis desse tipo. Se temos tudo isto podemos declarar métodos em qualquer lugar e isso é que se caracteriza como a sintaxe de closure porque ao declarar um literal o método verdadeiro que será criado dai, terá que ter um escopo e esse escopo segue as regras de closure.

Isto, obviamente , torna qualquer método em qualquer classe uma possivel closure. E torna possivel criar métodos do nada (anonimos).

O passo seguinte é apenas açucar sintático: se uma classe abstrata ou interface têm apenas um método, uma classe concreta pode ser criada simplesmente dizendo qual é a implementação desse método. Com objetos-método isto é trivial e portanto é suportado passar objetos-metodo onde este tipo de interfae seria esperado. Especialmente util para Runnnable e Callable e em Listeners.

Como qualquer objeto-metodo pode ser convertido para um objeto Method do reflection então ele têm implicitamente um método invoke que recebe parametros. Portanto ele é, pela definição que citou, uma inner-function.

A adição de closures faz valer a pena a espera. E já faz pensar na nova vaga de frameworks web que irão correr no JEE 6 com Servlet API 3 (que tem um monte de coisas boas).

pois é, acho que vaio ser mais fácil jogar tudo fora e começar de novo, pq no final das contas sairia mais barato.

Mas que sintaxe intrigante…

[quote] // function expressions
#(int i, String s) {
System.println.out(s);
return i + str.length();
}

// function expressions
#(int i, String s) (i + str.length())

// function types
#int(int, String)
[/quote]

fonte:
http://www.jroller.com/scolebourne/entry/more_detail_on_closures_in

Intrigante essa sintaxe ? :shock:

Tirando o “System.println.out” parece que nem estamos falando de java …

Agora, em relação à demora para a nova versão, acredito que não foram apenas desafios técnicos a serem superados. É claro que adicionar os elementos “atuais” à próxima versão do java demanda um certo tempo mas, acho q vcs esqueceram dos anos de 2008 e 2009 …

A Sun estava com problemas financeiros já há algum tempo. Como eles poderiam investir em mudanças drásticas para a nova versão do java sendo que eles não estavam conseguindo se manter ? Vimos nesse ano a compra da Sun pela Oracle. Será que isso não abalou os executivos da Sun ?

O que importa é que a estratégia financeira da Sun não estava funcionando e isso a Oracle percebeu. Será que o “Oraculo” pensa em mudanças fortes (quem sabe tirar o “openSource” do Java).
O que vcs acham ?

[]'s !

[quote=Artur Drummond]Intrigante essa sintaxe ?
O que importa é que a estratégia financeira da Sun não estava funcionando e isso a Oracle percebeu. Será que o “Oraculo” pensa em mudanças fortes (quem sabe tirar o “openSource” do Java).
O que vcs acham ?

[]'s ![/quote]

Se a oracle fizer isso ela enterra o produto.

[quote=Artur Drummond]Intrigante essa sintaxe ? :shock:

Tirando o “System.println.out” parece que nem estamos falando de java …
[/quote]

Bem pelo contrário. A sintaxe #() é usada no javadoc desde sempre e a nova proposta ( esse sample foi retirado da proposta CFJ (Closures for Java) que apareceu recentemente) é usado o return explicitamente
para retornar de dentro da closure. A proposta BCAA usava return para retornar do método envolvente e retorno implicito para retornar da closure.

A semântica da nova proposta é mais java friendly e se mapear para java.reflection.Method tanto melhor, ou seja, em todos esses blocos vc pode usar invoke mas tb qq reflection necessário no método como nome de parametetros anotations, etc… isso sim é poderoso.

[quote=sergiotaborda]
Bem pelo contrário. A sintaxe #() é usada no javadoc desde sempre [/quote]

Você não tá confundindo com as anchors HTML não? O javadoc costuma usar Classe.metodo ou apenas o nome do método diretamente. Só nos links HTML, claro eles usam os anchors, pra já dar focus no método desejado quando a página é carregada.

Acho que estão começando a “forçar a barra” com a linguagem Java… espero que não acabe virando um “C++ da vida” (estendendo a linguagem C)…

Seria melhor continuar focando esforços em aprimorar o suporte às linguagens dinâmicas na JVM, em vez de tentar fazer Java ser “a linguagem” para desenvolver todo e qualquer sistema.

[]´s

Na documentação da ferramenta Javadoc, aparece a notação #:

{@link package.class#member label}

Exemplo:

/**
 * Use the {@link java.lang.String#split(java.lang.String) } method instead.
 */

Por isso é que o Thingol dizia que “Java é o novo Cobol” - os coboleiros se mudaram com mala e cuia para cá. A resistência a inovações acaba sendo muito grande.

[quote=Alexandre Gazola]Acho que estão começando a “forçar a barra” com a linguagem Java… espero que não acabe virando um “C++ da vida” (estendendo a linguagem C)…

Seria melhor continuar focando esforços em aprimorar o suporte às linguagens dinâmicas na JVM, em vez de tentar fazer Java ser “a linguagem” para desenvolver todo e qualquer sistema.

[/quote]

O suporte a linguagens dinamicas já foi incluido para o java 7 (invoke dinamic) através de um novo bytecode e uma nova api.
O java é a lingua franca para um monte de outras linguagem e por isso ele precisa ter artefactos que essas linguagens têm. Isto porque se quer que uma closure scala possa ser invocada da mesma forma que uma em groovy ou jruby. Isso trás pradonização e a padronização trás otimizações. Neste momento cada scriptlang faz do seu jeito porque tem que contornar as limitações da linguagem java. Embora o byte code suporte closures não uma forma padrão das implementar.

A proposta de ter métodos como objetos de primeira classe não é o mesmo que closures, mas ajuda imenso na estratégia de padronização das invocações.