muito legal! curti pra caramba 
Java 7 What`s New, Performance Benchmark 1.5 1.6 1.7
http://www.taranfx.com/blog/?p=1754
Tem também o invokedynamic, quem sabe aumente a velocidade das chamadas aos métodos via reflection (o que vários frameworks fazem, como o hibernate, ou os mvcs web)
Melhor do que isso parece que ta difícil.
Acredito que é desnecessário. Gosto de closures, no entanto, em breve, quem sabe, pode ser possível você implementar o seu próprio closure utilizando o MPS (Meta Programming System), por exemplo. Vamos esperar o MPS amadurecer e ver se será aceito pela comunidade.
Acredito que é desnecessário. Gosto de closures, no entanto, em breve, quem sabe, pode ser possível você implementar o seu próprio closure utilizando o MPS (Meta Programming System), por exemplo. Vamos esperar o MPS amadurecer e ver se será aceito pela comunidade.[/quote]
Sem querer ser chato mas seu posto mostra o estado atual do Java onde nada é de graça mais. Quer closures, leva um framework. Não sei qual o nome disto mais é além do que cancer do ponto e vírgula.
Sim. É verdade. No entanto, eu penso que estão surgindo muitas outras linguagens e ferramentas como opção e acho um tanto injusto ficar esperando tanto do java 7. Acho que a tendência é migrar para novas linguagens e/ou DSL. No caso da DSL algumas ferramentas já estão criando formas de você reaproveitar sintaxe, expressões e etc… então, seria possível você herdar uma DSL idêntica ao java e implementar você mesmo os novos recursos de linguagem que você almeja. Pode ser que tenha uma curva de aprendizagem alta, mas tornaria muito mais fácil a evolução desta linguagem por uma comunidade que esteja interessada e ativa.
Acho que não vai haver mais nenhuma otimização quanto a propria jvm. O que tinham planejado sobre o java Kernel que ia sair pro Java 7 já foi lançado no Java 6_u12 ou 16 nao lembro.
Fora o GCG1 o novo Garbage Colector.
E mais umas coisinhas.
[quote=Bruno Laturner]http://www.infoq.com/articles/java7-module-system
Basicamente é para não deixar que APIs internas sejam vistas por classes de fora, e também facilitar a distribuição das APIs em partes, conforme elas são necessitadas.
Antes só tenho que avisar que é bem capaz dessa JSR não sair, até hoje não chegaram num acordo. Sem falar que veio o Projeto Jigsaw como uma espécie de concorrente, e também o OSGi que suprem bastante do que essa modularização visa a resolver.[/quote]
Valew pela explicação. Achei complicado, acho que também não sai.
Mas eu queria mais coisas no Swing (JTable). O coitado leva séculos para ganhar melhorias e eu sou um dos poucos que torce por ele 
Quanto ao multicatch, é uma proposta bem simples e fácil de implementar. Espero que venha no java 7.
Para quem não entendeu o que ela é:
try {
fazerAlgo();
} catch (MeuPrimeiroException ex) {
tratar(ex);
} catch (MeuSegundoException ex) {
tratar(ex);
} catch (MeuTerceiroException ex) {
tratar(ex);
}Ficaria assim:try {
fazerAlgo();
} catch (MeuPrimeiroException | MeuSegundoException | MeuTerceiroException ex) {
tratar(ex);
}
O tratamento no catch é o mesmo para todas estas exceções. A variável ex é do tipo da superclasse em comum a todas as exceções declaradas (normalmente Exception).
Mais além:
[code]public void foo() throws IOException, SQLException, FooException {
// …
}
public void goo() throws IOException, SQLException, FooException {
try {
foo();
} catch (final Throwable ex) {
fazerLog(ex);
throw ex;
}
}[/code]No java 6 este código não compila porque o throw do método goo() é para Throwable e a cláusula throws não contém Throwable. Já o compilador do java 7 será mais inteligente, ele verá que o corpo do try lança IOException, SQLException e FooException declaradas e possivelmente RuntimeException e Error que nunca são relevantes. O compilador detectará isso e saberá que o Throwable do catch deverá ser de uma dessas cinco classes ou possíveis subclasses (as três exceções declaradas por foo() mais RuntimeException e Error). Logo, Throwable não precisa ser declarado na cláusula throws, apenas as exceções que estão no corpo do try do método goo().
Sim. É verdade. No entanto, eu penso que estão surgindo muitas outras linguagens e ferramentas como opção e acho um tanto injusto ficar esperando tanto do java 7. Acho que a tendência é migrar para novas linguagens e/ou DSL. No caso da DSL algumas ferramentas já estão criando formas de você reaproveitar sintaxe, expressões e etc… então, seria possível você herdar uma DSL idêntica ao java e implementar você mesmo os novos recursos de linguagem que você almeja. Pode ser que tenha uma curva de aprendizagem alta, mas tornaria muito mais fácil a evolução desta linguagem por uma comunidade que esteja interessada e ativa.[/quote]
Se for herdar uma DSL idêntica do Java então não será uma DSL porque java não é uma DSL. Acho que esta fazendo alguma confusão. Uma característica das DSLs é terem uma curva de aprendizagem baixa. Voce deve estar falando de DSLs externas, é isso?
Bem, eu queria uma ferramenta decente para construir interfaces desktop, ao inves de uma IDE que usa 2 gb de memoria.
[quote=Mark_Ameba]Os safe-null operators sairam mesmo?
Até onde vi tava planejado mas não ia sair.
Isso seria algo muito interessante.
Não gosto de switchs então vou continuar não usando mesmo aceitando Strings.[/quote]
Sim Mark, vão sair.
[]s,
[quote=victorwss]Quanto ao multicatch, é uma proposta bem simples e fácil de implementar. Espero que venha no java 7.
[/quote]
Pelo que o Darcy disse (embora haja uma implementação do multicatch, infelizmente no protótipo do Gafter para closures - http://www.javac.info ) , cujo fonte não foi publicado), o multicatch não irá aparecer no Java 7. Alguma coisa deve ter sido descoberta pelo Gafter que deixa, na verdade, essa história do multicatch mais complexa que parece.
A curva de aprendizagem é baixa para ser usuário de uma DSL, no entanto, para você criar sua DSL a curva é altíssima. Por isso esperamos que surjam boas IDE’s (DSL Workbench) e boas linguagens para ajudar na criação de DSL. Se você já tem uma DSL para um domínio especifico pronta, pq não reaproveitá-la para então customizá-la? Ainda tem muita água pra rolar quanto a isso e discutir isso aqui vai chegar em lugar nenhum, rsrs 
Dê uma procurada pelos artigos do Fowler sobre DSL Workbench.
Obs: sim, estou falando de DSL Externa.
Até o PHP já tinha isso a anos…
String s = ...
switch(s) {
case "quux":
processQuux(s);
// fall-through
case "foo":
case "bar":
processFooOrBar(s);
break;
case "baz":
processBaz(s);
// fall-through
default:
processDefault(s);
break;
}
[quote=Thiago Senna]
[…]e boas linguagens para ajudar na criação de DSL.[…][/quote]
Essas ja existem. Procure por Groovy, Scala, Clojure. Mas obviamente estou falando de DSLs internas que são relativamente mais fáceis de serem criadas.
E a nova API de Data e Hora, o que acham ? rsrs
javax.time
Por exemplo, para subtrair quatro anos de uma data
date = date.withYear(2009).withMonthOfYear(5).withDayOfMonth(10);
date = date.minusYears(4);Que mudança !
sobrecarga de operadores, nada né?
[code]
BigDecimal s1 = new BigDecimal("10");
BigDecimal s2 = new BigDecimal("10");
BigDecimal result = s1 + s2;[/code]
odeio esses métodos add, sub, e afins do BigDecimal. O código fica totalmente ilegivel, alé de ser totalmente improdutivo.
talvez no java 8?
O que me deixa cheateado é que certas “coisinhas” poderiam ser implementadas sem nenhum problema… apenas alterando o proprio javac… e nao a VM (como no caso do bigdecimal , do Multicatch) e os caras simplesmente se negam a fazer isso…
é lamentavel…