Arquivo Discussoes de Programacao e Tecnologia 
Os responsáveis pelas três possíveis propostas para closures na linguagem Java se chegaram a um acordo para a implementação da funcionalidade e escreveram uma proposta de JSR para ser submetido ao JCP. Segundo Neil Gafter, apenas um dos autores envolvidos não concordou com a proposta, então eles acreditam que chegaram o mais próximo possível do consenso.
Notícia completa: Consensus Reached on Java Closures Proposal
Você acha que a proposta é realmente interessante?
Depois da 308 podem fazer o que quiserem…
O que tem de tão ruim na 308??
Vê lá…
Se alguém deu uma olhada na proposta, poderá ver que o Osvaldo Pinali Doederlein (que escreve regularmente na Java Magazine), e o Hani Suleiman, aquele honorável e coprolálico senhor, o também participam dessa JSR.
Será que ela será aprovada?
rs… boa resposta para um fórum. http://pt.wikipedia.org/wiki/Fórum_de_discussão
Desculpe a minha ignorância, mas se eu perguntei é porque nao sei onde encontrar esta informacao…
é… mas para que serve o google?? rs… vou procurar por lá.
De qualquer forma obrigado,
[]s
Nadilson, só para lhe ajudar:
a tal “308” é uma nova proposta para “Annotations”, que estende a JSR 305:
Muito obrigado mesmo, thingol!!
Abraços,
Nadilson
Peraí, eu li direito, ou java vai virar POA?(Programação Orientada a Anotações)???
[b]
method receivers:
public int size() @Readonly { … }
generic type arguments:
Map<@NonNull String, @NonEmpty List<@Readonly Document>> files;
arrays:
Document[@Readonly] docs1;
Document[][@Readonly] docs2 = new Document[2][@Readonly 12];
(docs1 is an unmodifiable one-dimensional array of mutable Documents.
docs2 is a mutable array whose elements are unmodifiable one-dimensional arrays of mutable Documents.)
typecasts:
myString = (@NonNull String)myObject;
type tests:
boolean isNonNull = myString instanceof @NonNull String;
object creation:
new @NonEmpty @Readonly List(myNonEmptyStringSet)
type parameter bounds:
class Folder { … }
class inheritance:
class UnmodifiableList implements @Readonly List<@Readonly T> { … }
throws clauses:
void monitorTemperature() throws @Critical TemperatureException { … }
[/b]
:roll:
Preparem-se pra queimar os dedos na tecla @…
Depois da JSR 308, só falta agora herança múltipla, aritmética com ponteiros, overload de operadores, passagem por referencia, ponteiro para método e gerenciamento de memória. E tudo via annotation! Que máximo!!! :roll:
Olá
Você sabe perfeitamente que closure não tem nada a ver com sua lista mas realmente pior que sua lista só configuração programática que é coisa que a gente fazia, por falta de alternativa, no tempo do Clipper Autumn 86.
[]s
Luca
Luca,
Dá uma olhada aqui: http://www.google.com.br/search?q=Maracujina
Eu estava falando da 308!!! Não entendi o sua resposta agressiva.
E quanto a configuração programática, ela vai muito bem obrigado. Muitas pessoas usando! Guice do Google usando, Waffle usando, etc. Parece que não sou só eu que gosto de configuração programática, mas tudo bem… Logo outros frameworks vão passar a incentivar a configuração programática tb, vc vai ver…
Mas se vc não gosta, pode continuar usando XML e Annotations. Vc é livre para usar o que quiser…
Olá
Então me desculpe porque eu nem percebi pelo fato que na mensagem que eu li estava bem claro em azul:
Em todas as suas mensagens eu leio isto. Nunca mais vi você falando de assunto nenhum. É só esta insistente propaganda.
E eu continuo com minha opinião sobre frameworks MVC: não gosto de configuração programática ou de nenhum outro tipo de configuração que impeça que as mudanças sejam feitas pela equipe de suporte sem ambiente Java. Repare que falo de configuração de run time e não opções do programador.
[]s
Luca
Não sabia que isso estava te incomodando tanto assim. Assinatura removida, ok?
Sobre configurações:
Essas configurações tão burras e tão estáticas que um cara de suporte vai poder alterar podem até estar num arquivo texto, que será chupado pela sua configuração programática. Pode vir do banco também, onde o cara de suporte teria acesso via um front-end web para alterá-las/consultá-las.
O problema é quando todo e qualquer tipo de configuração está num arquivo XML gigantesco ou até mesmo espalhado pelo código inteiro na forma de annotations.
Configuração estática e burra = HOST do banco de dados, uma senha ou outra, etc.
Quando falo em configuração, penso em coisas mais complexas como páginas para a view, validação, listas, ioc, di, filtros, etc. e isso esse cara de suporte não deve mexer, estando em XML, Java, text ou annotations!
Confesso que eu não sabia lhufas sobre closures, mas depois de ler esse post e fuçar um pouco por ai, inclusive nesta explicação de 2004 do Martin Fowler a respeito, fiquei com a visão menos embaçada. Junto a isso, fui dar uma lida na tal JSR 308.
Aí fiquei imaginando eu abrindo aquele fonte feito por um programador Java 7 sedento por novidades e mágicas… aquele código cheio de <generics>, (closures) e @nnot@tions pra todo lado…
Vou ter pesadelos essa noite.
rs… boa resposta para um fórum. http://pt.wikipedia.org/wiki/Fórum_de_discussão
Desculpe a minha ignorância, mas se eu perguntei é porque nao sei onde encontrar esta informacao…
é… mas para que serve o google?? rs… vou procurar por lá.
De qualquer forma obrigado,
[]s
Eu não sabia q tu não conhecia o site 
Alguém já viu teclado com uns 4 ou 5 @ ?
rs… ok amigo… nao esquenta… e obrigado a todos pela elucidacao…
Bem, mas voltando a JSR… nao sei… mas nao gostei destas novas possiblidades para anotacoes; java tem uma sintaxe tao enxuta…
Mas eh certo que esta proposta vai ser implementada?
Do jeito que as coisas vao indo… eh bem por ai mesmo…