Afinal, haverá Closures no Java 7?

34 respostas
Paulo_Silveira

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.

34 Respostas

Luca

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

L

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.

faelcavalcanti

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?

Rubem_Azenha

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:

maior_abandonado

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:

Raphael_Lacerda

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

C

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.

J

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.

sergiotaborda

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.

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

B

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

peczenyj

Mas que sintaxe intrigante…

<blockquote>  // 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)

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

A

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 !

J

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 !

Se a oracle fizer isso ela enterra o produto.

sergiotaborda

Artur Drummond:
Intrigante essa sintaxe ? :shock:

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

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.

rael_gc

sergiotaborda:

Bem pelo contrário. A sintaxe #() é usada no javadoc desde sempre

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.

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.

[]´s

E

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.
 */
E

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.

sergiotaborda

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.

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.

J

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.

[]´s


Não entendi o c++ da vida.
Toda linguagem tem que evoluir. É pior ficar criando várias linguagenzinhas para cada problema.

B

A tendência que temos hoje é criar linguagens específicas para resolver problemas específicos. É melhor que criar um pato que nada, anda e voa, mas não é ótimo em nenhuma dessas tarefas.

J

A tendência que temos hoje é criar linguagens específicas para resolver problemas específicos. É melhor que criar um pato que nada, anda e voa, mas não é ótimo em nenhuma dessas tarefas.

Uai, e o java não atende suas necessidades?
Imagino que ter que ficar alternando entre várias linguagens pode ser ainda mais cansativo.

sergiotaborda

A tendência que temos hoje é criar linguagens específicas para resolver problemas específicos. É melhor que criar um pato que nada, anda e voa, mas não é ótimo em nenhuma dessas tarefas.

Cuidado. Criar DSL e criar Linguagens de Programação são coisas bem diferentes. Linguagens como ruby,e groovy ou javascript podem ser uma boa base para criar DSL mas são uma linguagem de programação só.

Java é uma linguagem de utilidade genérica o que significa que a sua preocupação não é em criar DSL.

J

marcosalex:
juliocbq:

Uai, e o java não atende suas necessidades?
Imagino que ter que ficar alternando entre várias linguagens pode ser ainda mais cansativo.

São dois mercados distintos. Linguagens pra um domínio específico x linguagens de uso geral.
Já trabalhei com VHDL, uma linguagem pra fazer especificação e simulação de hardware. Inclusive no meu mestrado usei Haskell pra fazer um compilador funcional mais eficiente e simples que o VHDL.

O flex e o Bison também fazem isso e são bibliotecas para c++, e existem também para java. Por isso penso que não há necessidades de tantas variações.
Já usei prolog para criar sistemas especialistas e resolver problemas de busca em profundidade, mas poderia facilmente fazer com java ou c++, ou c# também.
Acho mais fácil evoluir a linguagem que criar uma outra para certos problemas

J

marcosalex:

Questão de gosto.
E o flex e bison são bem mais limitados que o VHDL, principalmente se você trabalhar com FPGAs. As bibliotecas teriam de evoluir muito ainda, enquanto o outro é focado.


Eu nunca usei vhdl, vou pesquisar para ver como funciona.

rael_gc
entanglement:
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.
 */

Isso é exatamente pra gerar o anchor HTML do link (#). Se closure usar # é para imitar anchor HTML.

E

A idéia (que está nas propostas FCM e CFJ) é usar o “#” para significar uma referência a um método qualquer. Ficaria mais claro (e além disso seria mais adequado para o uso com “invokedynamic”) que criar “inner classes”.

Por exemplo:

class ExemploOrdenacao {
    public static int comparar (String c1, String c2) {
        return c1.compareTo (c2);
    }
    public static int compararDecrescente (String c1, String c2) {
        return c2.compareTo (c1);
    }
    public static int compararIgnorandoMaiusculas (String c1, String c2) {
        return c1.compareToIgnoreCase (c2);
    }
    public static void main (String[] args) {
        String[] s = {"abc", "def", "ghi" };
        Arrays.sort (s, #comparar(String,String) );
        Arrays.sort (s, #compararDecrescente(String,String) );
        Arrays.sort (s, #compararIgnorandoMaiusculas(String,String) );
    }
}
Rafael_Afonso

Fonte: http://www.java.net/story/openjdk-project-lambda-approved

Da home do Project Lambda:

Fonte: http://openjdk.java.net/projects/lambda/

C

No início do ano vi algumas notícias dizendo que não vai ter closures no Java 7.

A dúvida ainda continua no ar: vai ter ou não vai ter closures no Java 7?

J

marcosalex:
ceklock:
No início do ano vi algumas notícias dizendo que não vai ter closures no Java 7.

A dúvida ainda continua no ar: vai ter ou não vai ter closures no Java 7?

Bom, o Java 7 sai esse ano, daí a gente vai descobrir. heheheh

amém.

nofan

Vale a pena dar uma lida nesse artigo

C

Eu não sei não… Acho que essa história de closures pode trazer danos ao Java. Quem quer “lambda expressions” pode usar uma linguagem de script pra isso.

Pra falar a verdade ainda não entendi qual vai ser a grande vantagem de usar closures.

P.S: interessante o artigo citado acima.

nofan

ceklock:
Eu não sei não… Acho que essa história de closures pode trazer danos ao Java. Quem quer “lambda expressions” pode usar uma linguagem de script pra isso.

Pra falar a verdade ainda não entendi qual vai ser a grande vantagem de usar closures.

A vantagem maior é pros desenvolvedores de ferramentas e frameworks e não pro desenvolvedor comum.

nofan

Java 7 : Oracle pushes a first version of closures

http://www.baptiste-wicht.com/2010/05/oracle-pushes-a-first-version-of-closures/

Criado 18 de novembro de 2009
Ultima resposta 30 de mai. de 2010
Respostas 34
Participantes 20