[Java 7] As alterações aprovadas:

Assuntos Gerais Notícias
#21

E como ele vai saber o que deve ser colocado nesse fainally magicamente gerado?

Nem toda classe implementa Closeable. É só para Closeables?

#22

Muito bom a Collection Literals, é uma das coisas que eu mais sentia falta em Java

Só é uma pena botarem essa palhaçada de Automatic Resource Management mágico ao invés de nos darem closures, que serviriam pra fazer isso e muito mais

#23

[quote=Paulo Silveira]E como ele vai saber o que deve ser colocado nesse finally magicamente gerado?

Nem toda classe implementa Closeable. É só para Closeables?[/quote]

Esse ARM é para classes que implementam Disposable (no caso do .NET o “using” é só para classes que implementam IDisposable).

Ele chamaria o novo método “dispose”, que as classes que querem aproveitar o recurso de ARM devem implementar, e que faria o tal do “close com try/catch”, por exemplo.

Isso é mais um prego no caixão dos “finalizers”, que são uma péssima idéia que foi implementada no Java desde os primórdios.

#24

[quote=paulo.ubuntu]Até que enfim o java está começando a sair do forno, em outro posto comentei que estava com a impressão que o java tava esfriando, com mudanças assim acredito que melhore um pouco.

a unica coisa que senti falta foi de multiplos catch

try{
 //Alguma Coisa
}catch(NumberFormatException,AlgumaException ex){
//Algum Tratamento
}

Acho que isso ia quebrar um galhão[/quote]

Quebra um galho, mas não faço a mínima idéia como invocaria métodos dessas exceções. Qual o tipo de ex?

Algo como

try{
 //Alguma Coisa
}catch(NumberFormatException|AlgumaException extends Exception ex){
//Algum Tratamento
}

baseado no generics daria um tipo para resolver o ex, e pode usá-lo em build time.

#25

[quote=Bruno Laturner][quote=paulo.ubuntu]Até que enfim o java está começando a sair do forno, em outro posto comentei que estava com a impressão que o java tava esfriando, com mudanças assim acredito que melhore um pouco.

a unica coisa que senti falta foi de multiplos catch

try{
 //Alguma Coisa
}catch(NumberFormatException,AlgumaException ex){
//Algum Tratamento
}

Acho que isso ia quebrar um galhão[/quote]

Quebra um galho, mas não faço a mínima idéia como invocaria métodos dessas exceções. Qual o tipo de ex?

Algo como

try{
 //Alguma Coisa
}catch(NumberFormatException|AlgumaException extends Exception ex){
//Algum Tratamento
}

baseado no generics daria um tipo para resolver o ex, e pode usá-lo em build time.[/quote]

isso que você chamou de “baseado em generics”, já não existe!? (mas não tem nada a ver com generics).
ex:

try {}catch(Exception e){}
já trata qualquer classe que herde Exception.

E sobre generics em tempo de execução!? nops.

#26

[quote=vaninh0]isso que você chamou de “baseado em generics”, já não existe!? (mas não tem nada a ver com generics).
ex:

try {}catch(Exception e){}
já trata qualquer classe que herde Exception.

E sobre generics em tempo de execução!? nops.[/quote]

Leia novamente sobre o que estou falando. Não quero pegar todas as exceptions.

#27 
List<Integer> powersOf2 = {1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024};
Map<String, Integer> ages = {"John" : 35, "Mary" : 28, "Steve" : 42};

lembra bastante json :-o

static String readFirstLineFromFile2(String path) throws IOException
{
    try (BufferedReader reader = new BufferedReader(new FileReader(path))
    {
        return reader.readLine();
    }
    // reader.close() é chamado automaticamente
}

esse aqui vai ser muito bom pra treinar estagiario a não fechar conexão com o banco :XD:

#28

Putz, não vai ter properties? :frowning:

#29

JSR 294 Improved Modularity Support (superpackages)

superpackage example.bar.lib {   
  
    // member packages   
    member package example.bar.lib;   
  
    // member superpackages   
    member superpackage example.bar.lib.net, example.bar.lib.xml;   
  
    // list of exported types   
    export example.bar.lib.Table;   
  
    export superpackage example.bar.lib.net;   
}

alguem ajuda a entender? Sei que tem a ver com visibilidade mas não entendi patavinas.

#30

[quote=mvargens]JSR 294 Improved Modularity Support (superpackages)

superpackage example.bar.lib {   
  
    // member packages   
    member package example.bar.lib;   
  
    // member superpackages   
    member superpackage example.bar.lib.net, example.bar.lib.xml;   
  
    // list of exported types   
    export example.bar.lib.Table;   
  
    export superpackage example.bar.lib.net;   
}

alguem ajuda a entender? Sei que tem a ver com visibilidade mas não entendi patavinas.[/quote]

A notação agora é diferente:

//org/netbeans/core/module-info.java @Version("7.0") @ImportModule(name="java.se.core", version="1.7+") module org.netbeans.core; 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.

#31

Interessante a iniciativa espero que estas mudanças vinguem seria duas “mãos na roda” bom post

#32

coisinhas uteis…

#33

Posso estar errado… mas não ter inclusido closures foi a cagada do ano na tencologia java… talvez a maior dos ultimos anos…

#34

[quote=chun]Posso estar errado… mas não ter inclusido closures foi a cagada do ano na tencologia java… talvez a maior dos ultimos anos…

[/quote]

Não sei se concordo. Closures as vezes me parece ser algo que seria muito “artificial” na linguagem Java, sei lá…

#35

[quote=gangrel-br][quote=chun]Posso estar errado… mas não ter inclusido closures foi a cagada do ano na tencologia java… talvez a maior dos ultimos anos…

[/quote]

Não sei se concordo. Closures as vezes me parece ser algo que seria muito “artificial” na linguagem Java, sei lá…[/quote]

Seriam maravilhosas do ponto de vista de uma serie de frameworks…
e com certeza resultaria em uma dimunuicao benigna da verbosidade de Java.

#36

Galera, e a velocidade do java 7, vai superar a do java 6? Isso depende da jdk, ou existe uma velocidade “minima” para as jdks? Eu me lembro quando atualizei minha jdk da 1.4 para a 5… tive uma enorme impressão de aumento de velocidade…

#37

Sinto te desapontar… mas acredito que não erá tem um grande ganho…

#38

[quote=chun]Seriam maravilhosas do ponto de vista de uma serie de frameworks…
e com certeza resultaria em uma dimunuicao benigna da verbosidade de Java.[/quote]

Pior que a maioria das propostas de closures parecem piorar a verbosidade da linguagem, ou fogem muito ao padrão da linguagem.

#39

"

#40

Boa, antes do post do Luca eu estava me perguntando se a versão ia ser mesmo só um monte de syntax suggars.
Não que eles não facilitem a vida mas não acrescentaram nada de realmente novo à linguagem.