[Java 7] As alterações aprovadas:

Olá:

Saiu a relação das alterações aprovadas para Java 7:

[list]Simplified Generics: Uso da diamond notation:[/list]

[list]Collection Literals:[/list]

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

[list]Automatic Resource Management[/list]

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

[list]String em Switchs[/list]

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;
}

[list]Binary Literals[/list]

// An 8-bit 'byte' literal.
byte aByte = (byte)0b00100001;

// A 16-bit 'short' literal.
short aShort = (short)0b1010000101000101;

// Some 32-bit 'int' literals.
int anInt1 = 0b10100001010001011010000101000101;
int anInt2 = 0b101;
int anInt3 = 0B101; // The B can be upper or lower case as per the x in "0x45".

// A 64-bit 'long' literal. Note the "L" suffix, as would also be used
// for a long in decimal, hexadecimal, or octal.
long aLong =
0b01010000101000101101000010100010110100001010001011010000101000101L;

[list]Simplified Varargs Method Invocation[/list]

/*
*EXAMPLES
*
Before this change:
*/
  static <T> List<T> asList(T... elements) { ... }

  static List<Callable<String>> stringFactories() {
    Callable<String> a, b, c;
    ...
    // Warning: **"uses unchecked or unsafe operations"*
    return asList(a, b, c);
  }

//After this change:

  // Warning: **"enables unsafe generic array creation"*
  static <T> List<T> asList(T... elements) { ... }

  static List<Callable<String>> stringFactories() {
    Callable<String> a, b, c;
    ...
    return asList(a, b, c);
  }

[size=9]Este confesso que não entendi[/size] :frowning:

[list][url=http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001131.html]language support for JSR 292/url[/list]

Object x = Dynamic.getMeSomething();

Fontes:


http://blogs.sun.com/darcy/entry/project_coin_final_five

[quote=Rafael Afonso]
[list]Simplified Varargs Method Invocation[/list]

/*
*EXAMPLES
*
Before this change:
*/
  static <T> List<T> asList(T... elements) { ... }

  static List<Callable<String>> stringFactories() {
    Callable<String> a, b, c;
    ...
    // Warning: **"uses unchecked or unsafe operations"*
    return asList(a, b, c);
  }

//After this change:

  // Warning: **"enables unsafe generic array creation"*
  static <T> List<T> asList(T... elements) { ... }

  static List<Callable<String>> stringFactories() {
    Callable<String> a, b, c;
    ...
    return asList(a, b, c);
  }

[size=9]Este confesso que não entendi[/size] :frowning: [/quote]

No final do email tem links falando sobre o problema, este achei o melhor: http://tech.puredanger.com/2007/02/27/generics-array-construction/

O problema fundamental é instanciar Arrays, que são tipos verificados em tempo de compilação, usando generics (tempo de execução), onde seus tipos são apagados, e ainda manter tipagem forte.

Dá até pra fazer isso, mas com muita criatividade e magia negra.

excelente post!

todas mudancas bem pequenas, mas vao ajudar bastante.

uma pena que a grande maioria das mudancas maiores foram engavetadas. especialmente reificação de tipos genéricos, structs (objetos na pilha, por assim dizer) e outras coisinhas mais.

Sweeeeeeeeeeeeeeeet! :smiley:

Até as empresas homologarem o Java 7 vai demorar!

Faltou lembrar do Elvis Operator e do Null-Safe Navigation. (ambos que vieram do Groovy)

O Elvis Operator (Operador Elvis, “está vivo, não morreu, apesar de você não vê-lo”) é uma maneira simplificada para usar a atribuição de valores a variáveis com operadores ternários, levando-se em consideração que 90% dos casos onde usamos os operadores ternários, são para validar se um objeto é null ou não. Exemplo.

//maneira atual
String reqParameter = ...
String myValue = (reqParameter != null) ? reqParameter : "0";

//Elvis Operator
String reqParameter = ...
String myValue = reqParameter ?: "0";

Já o Null-Safe Navigator, é uma maneira, como dizem os Rubistas e Groovistas (esquisito né), “açucarada” de navegar em objetos e seus filhos. Ele faz uma validação se o objeto onde está se chamando um método é null ou não, para neste caso, efetuar a chamada mesmo.

//maneira antiga
if (objX != null) {
   if (objY != null) {
      if (objZ != null) {
         System.out.println (objX.objY.objZ.getValue());
      }
   }
}

//Null-Safe Navigation
System.out.println (objX?.objY?.objZ?.getValue());

[]s,

Eu não sei quanto à vocês, mas estou com um alívio de não ter que ficar criando enum pra switch besta… Achei todas as alterações muito interessantes!

bizarro esse “Automatic Resource Management”… o que vai ter de gente usando errado isso (achando que fecha mas nao fecha)…

pra mim eh desnecessario…

[quote=Sergio Lopes]bizarro esse “Automatic Resource Management”… o que vai ter de gente usando errado isso (achando que fecha mas nao fecha)…

pra mim eh desnecessario…[/quote]

Sergio, como deverá ser feito com a nova mudança ?

grande abrassss

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.

O que estou sentindo falta é a inclusão da nova API de date/time, inspirada na Joda Time. Pelo menos até agora não vi nenhuma confirmação de que ela será incluída.

[quote=Sergio Lopes]bizarro esse “Automatic Resource Management”… o que vai ter de gente usando errado isso (achando que fecha mas nao fecha)…

pra mim eh desnecessario…[/quote]

Já tem muita gente esquecendo de fechar recursos que abriram, isso pelo menos ajuda a aliviar o peso sobre o programador.

Olá

Também gostei do post.

Quanto a notícia lamento algumas ausências tais como Improved Exception Handling for Java (esta ausência dói um pouco) e Large arrays

Além do que descreve o post acho (não tenho certeza) que serão incluídas mais coisas tais como Acréscimos na API de concorrência (Fork/Join e TransferQueue) e Acréscimos no Java.NIO (Improved filesystem interface, Complete socket-channel functionality, Support asynchronous I/O.Ver também:



http://openjdk.java.net/projects/nio/resources/AsynchronousIo.html

Também deve ser incluído Type Annotations (JSR 308 ) and the Checker Framework e a nova API Date/Time (assim espero)

Strings no switches vem com 10 anos de atraso. Teria sido muito mais útil nos primórdios do Java. Agora já nos acostumamos a viver com o mínimo de switch/case

language support for JSR 292 (invokedDynamic) não mudará a vida do programador Java comum que programa somente em Java mas pode ajudar no desenvolvimento de sistemas interoperando (eita palavrinha horrorosa…) com outras linguagens que usam a JVM. Também ajudará a quem quiser implementar na JVM outras linguagens usando Java.

Outros links:
http://blogs.sun.com/darcy/resource/JavaOne/J1_2009-TS-4060.pdf
http://blogs.sun.com/darcy/
http://blogs.sun.com/darcy/entry/project_coin_final_five
http://blogs.sun.com/darcy/entry/project_coin_consideration_round_2
http://blogs.sun.com/darcy/entry/project_coin_week_1_update

Coisas a mais que existem por aí e que poderiam fazer parte do Java SE:

  • A API de servlets e algo similar ou o próprio HttpClient
  • A API de logging deveria ser jogada fora em troca de algo como o que já existe por aí tal como SLF4J ou mesmo o LOG4J, ver links em http://www.theserverside.com/news/thread.tss?thread_id=47120 (se bem que hoje em dia logs combinam bem com armazenamentos do tipo Key/value tais como CouchDB, MongoDB, cassandra, redis e similares)
  • API para json

[]s
Luca

E closerus está confirmado mesmo para essa versão?! Achei interessante Collection Literals, já a Diamond Notation e a Management Resource eu não gostei pois prefiro algumas coisas bem explícitas e claras!

Agora uma pergunta que me veio a cabeça, no caso da Collection Literals, qual implementação de List que ela irá usar?! :shock: :?: , e no caso do Map?!

[quote=thiago.correa]E closerus está confirmado mesmo para essa versão?! Achei interessante Collection Literals, já a Diamond Notation e a Management Resource eu não gostei pois prefiro algumas coisas bem explícitas e claras!

Agora uma pergunta que me veio a cabeça, no caso da Collection Literals, qual implementação de List que ela irá usar?! :shock: :?: , e no caso do Map?![/quote]
Que eu saiba closures foi abandonado. Quanto aos literals eu apostaria em ArrayList e em HashMap.

Aqui está uma página com o status das features propostas para o Java 7: http://tech.puredanger.com/java7

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

Isso tem, só que em vez da vírgula é um |.

Mostre um exemplo

[quote=Bruno Laturner][quote=Sergio Lopes]bizarro esse “Automatic Resource Management”… o que vai ter de gente usando errado isso (achando que fecha mas nao fecha)…

pra mim eh desnecessario…[/quote]

Já tem muita gente esquecendo de fechar recursos que abriam, isso pelo menos ajuda a aliviar o peso sobre o programador.[/quote]

Acredito que só vai ser fechado quando for coletado pelo gc, e pensando que esta seguro com o gc, muitos que declaram as Streams no escopo de classe (ou qualquer motivo que faça o Stream não ser coletado) vão pensar: “Oba, tudo fechadinho” e creio que não será bem assim. (acho que isso que o Bruno quis dizer)

“Automatic Resource Management” é uma coisa excelente.

No .NET, por exemplo, eu exijo que o programador sempre use “using” para deixar sempre arquivos, resources GDI e outras tranqueiras bem fechadinhas quando necessário, para evitar problemas.

Agora sim, vamos ver programas que fecham direito arquivos. Isto:

try (BufferedWriter bw = new BufferedWriter (new OutputStreamWriter (new FileOutputStream ("teste.txt")))) {
    bw.writeLine ("Hello, world!);
}

é muito mais seguro, claro e fácil de usar que isto aqui:

BufferedWriter bw = null;
try {
    bw = new BufferedWriter (new OutputStreamWriter (new FileOutputStream ("teste.txt")))) {
    bw.writeLine ("Hello, world!);
} finally {
    if (bw != null) try { bw.close(); } catch (IOException ex) {}
}