[Java 7] As alterações aprovadas:

111 respostas
R

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

111 Respostas

B

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:

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.

P

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.

C

Sweeeeeeeeeeeeeeeet! :smiley:

Até as empresas homologarem o Java 7 vai demorar!

L

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,

A

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!

S

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

pra mim eh desnecessario…

R

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…

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

grande abrassss

M

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.

R

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.

B

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…

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

L

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

T

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?!

R

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?!


Que eu saiba closures foi abandonado. Quanto aos literals eu apostaria em ArrayList e em HashMap.

R

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

P

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

R

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

G

Mostre um exemplo

V

Bruno Laturner:
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…

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

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)

E

“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) {}
}
P

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

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

V

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

E

Paulo Silveira:
E como ele vai saber o que deve ser colocado nesse finally magicamente gerado?

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

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.

B

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

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.

V

Bruno Laturner:
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

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.

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.

B

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.

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

W
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:

M

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

M

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.

B

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.

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.

L

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

A

coisinhas uteis…

C

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

J

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

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

C

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

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

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

F

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…

C

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

B

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

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

M

"

V

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.

L

muito legal! curti pra caramba :stuck_out_tongue:

V

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)

M

Melhor do que isso parece que ta difícil.

T

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.

M

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.

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.

T

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.

M

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.

B

Falando de DSLs e outras linguagens, me apaixonei por esta aqui:

http://www.scala-lang.org/node/138

M

Fora o GCG1 o novo Garbage Colector.
E mais umas coisinhas.

M

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.

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 :frowning:

V

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:

public void foo() throws IOException, SQLException, FooException {
    // ...
}

public void goo() throws IOException, SQLException, FooException {
    try {
        foo();
    } catch (final Throwable ex) {
        fazerLog(ex);
        throw ex;
    }
}
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().
M

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.

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.

L

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.

Sim Mark, vão sair.

[]s,

E

victorwss:
Quanto ao multicatch, é uma proposta bem simples e fácil de implementar. Espero que venha no java 7.

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.

T

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 :wink: Dê uma procurada pelos artigos do Fowler sobre DSL Workbench.

Obs: sim, estou falando de DSL Externa.

J

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

Thiago Senna:

[…]e boas linguagens para ajudar na criação de DSL.[…]

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.

Y

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 !

M

sobrecarga de operadores, nada né?

BigDecimal s1 = new BigDecimal("10");
		BigDecimal s2 = new BigDecimal("10");
		
		BigDecimal result = s1 + s2;

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? :(

C

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…

L

Olá

chun:
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…

Chun, o que escrevo abaixo não é diretamente para você mas para todos nós que estamos nos lamentando de que falta isto ou aquilo.

Frases tiradas de http://blogs.sun.com/darcy/resource/JavaOne/J1_2009-TS-4060.pdf

[color=darkblue]Asking the right question…Why don’t you…

A better question… Why don’t we…

Project Coin

Participatory effort! Call for proposals:
● Write a detailed proposal
● Prototype optional
● Analysis and critiques on open mailing list
[/color]

Porque poucos brasileiros participam? Somos chupins?

O projeto foi feito justamente para facilitar a participação de gente de todo o mundo. E como está escrito acima, nem precisava escrever muito código. Bastava um protótipo para ilustrar a proposta.

[]s
Luca

S

chun:
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…

A Sun em particular tem muito cuidado com o que coloca na especificação do Java. E existem implicações além do que nós- comuns utilizadores - percebemos. às vezes uma alteração não entra porque viola algum dos principios do Gosling. Por exemplo, porque java não tem suporte nativo para o operador + para bigdecimal se o tem para String ?
Porque String é um objetivo java.lang e bigdecimal é java.math. Ou seja,String é essencial para java,bigdecimal não é.
E o bigdecimal tinha muitos problemas no inicio. Era implementado nativamente por causa de performace via jni e não permitia fazer calculos corridos. Por isso a IBM propos a class MathContext.

BigDecimal evolui muito porque foi utilizado muito. Agora que cada vez mais é utilizado, vem a demanda de operadores.

Mas quanto resulta de new BigDecimal(“1”).divide(new BigDecimal(“3”)) ? Resulta ArithmeticException.
Isso não é o que vc espera quando faz 1/3… Portanto, colocar + e - seria trivial, mas / e * não.
Por isso está sendo melhor investigada essa opção.

Lembrem-se que todo o guarda-chuva java 7 eram sugestões. Algumas entram, outras não. Isso não diz nada sobre o mérito da sugestão,nem que elas não podem ser adicionadas no futuro.

O foco do java 7 ( por ser uma versão impar) é o miolo do java. Mas desta vez a jvm e não o compilador como no java 5. Por isso o foco foi em adicionar invokedynamic (que acelera o desenvolvimento de novas linguagens para a jvm,inclusive as que suportam operações com bigdecimal como groovy). A ideia é : se existe em outra lignaugem da jvm vamos dar velocidade nisso em vez de colocar no Java e mudar o compilador. O projeto coin são pequenas alterações no compilador. Na realidade,quase que nem no compilador e sim na linguagem em si que permite literais. Repare que isso seria impossivel sem auto-boxing.

As coisas estão interligadas e existem dependencias. Por exemplo, a proposta de closures dependeria de introduzir um pacotefatasma de interfaces e o invokeDynamic. Essa coisa do pacote fantasma não é elegante (um dos principios do Gosling) e por isso ficou na geladeira. Espera-se que até o java 9 a implementação melhore para algo mais inteligente (tlv surripiando o que o groovy faz), contudo a peça que faz funcionar, já está lá : o invokedynamic. O uso deste novo tipo de invocação/reflection/método tem muitas implicações práticas que ainda vão ser vista nos proximos anos, e isso terá uma nova luz ao problema das closures.

quanto a performance, o Java 7 é sem duvida melhor devido a várias alterações feitas na jvm. o G1 é o mesmos interessa aqui,porque as features boas já existem quase todas no java 6 só que nos updates. Nem todo o mundo atualiza os jre ejdks,mas existem muitos forward ports de funcionalidades de performance. As mais novas são a melhor integração com a api gráfica nativa para aumentar a performance do swing e fx e a API de paralelização que permite acelerar calculos e algoritmos em geral tirando partido dos multicore hoje já comuns.

Só lembrando que no dia 30 de Outubro de 2009 o Java 5 sairá de linha. Java 7 não é apenas melhor,mais rápido e com melhor suporte a outra linguagens na jvm. Ele é, tb, inevitável.

(P.S. A API de Path é show e há muito tempo pedida ,mais que closures :wink: e só agora a temos)

C

sergiotaborda…

Olá ! Vamos por partes :smiley:

  1. Primeiramente esse negocio de abordar apenas a JVM no Java7 é balela, pois no java5 (onde ouve mudanca na linguagem) muita coisa foi implementada apenas pelo javac (ex: Generics)… justamente para evitar uma mudanca brusca na JVM… Sim… poderiamos ter varias outras solucoes do tipo (inclusive o bigDecimal)

  2. Esse negocio de 1/3 gerar uma exception já existe até em tipos primitivos, entao esta disculpa nao cola:

int a = 1;

int b = 0;

int c = a/b; // BOOM !
  1. Closures em java… incluindo ou nao um pacote fantasma , abriria o leque para diminuicao da verbosidade de Java… e isso seria muito bom… alem do que poder utilizar “function pointers” eh algo muito util para coisas nao triviais…

Esse negocio de “ter que analisar melhor” eh pura balela… tem tempo suficiente para fazerem isto…

C

Luca:
Olá

chun:
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…

Chun, o que escrevo abaixo não é diretamente para você mas para todos nós que estamos nos lamentando de que falta isto ou aquilo.

Frases tiradas de http://blogs.sun.com/darcy/resource/JavaOne/J1_2009-TS-4060.pdf

[color=darkblue]Asking the right question…Why don’t you…

A better question… Why don’t we…

Project Coin

Participatory effort! Call for proposals:
● Write a detailed proposal
● Prototype optional
● Analysis and critiques on open mailing list
[/color]

Porque poucos brasileiros participam? Somos chupins?

O projeto foi feito justamente para facilitar a participação de gente de todo o mundo. E como está escrito acima, nem precisava escrever muito código. Bastava um protótipo para ilustrar a proposta.

[]s
Luca

Luca ,

E voce acha realmente que NINGUEM entrou lá para sugerir o Multicatch ? Com certeza sugeriram e mesmo sabendo da GRANDE utilizade do mesmo não foi implantado…

S

chun:
sergiotaborda…

Olá ! Vamos por partes :smiley:

É,vamos,porque parece que não fui claro.

O que eu disse foi: versões impares atacam o miolo do java:jvm,compiladores,e outras ferramentas do sdk como javadoc.
No 5 o compilador foi o cara. Novos bytecodes não foram introduzidos. a JVM não mudou (ela foi mantida,é diferentes).
No 7 o compilador é que foi mantido e foi a jvm que mudou. Novos bytecodes foram adicionados (invokedynamic)

Ou seja, no 5 o foco era alterar a linguagem e a jvm foi atrás. no 7 o foco é alterar a jvm e a linguagem foi atrás.
Generics foi implementado apenas por truques de compilação sem mudar o byte code. My point exactly.

Lol…achei que era obvio que estavamos falando de numeros decimais (BigDecimal).
O ponto é que bigdecimal substituiria Double. 1/3 com double não dá erro. com devide dá.
Para não dar vc precisa passar um MathContext implicatamente ou explicitamente.
Esta necessidade fica escondida com o uso do operador /. NO grrovy que usa isso,é feito um arredondamento forçado.
Isso não é uma boa opção no caso geral e Java é uma linguagem de uso geral (ao contrário de groovy que é linguagem de script)

Sim, poderiam ter ido com a proposta atual.Mas isso tem implicações no futuro. Um dos principios do Gosling é que sempre haja retrocompatibilidade ou seja,todas as aplicações 1.0 tem que correr na jvm.
Se no 7 liberassem isso e no 9 se arrependencem e liberassem de outra forma,seria um desastre porque aplicações pré-9 não funcionariam. Como isso é algo no bytecode então tem que ser avaliado com muito cuidado.

Eu perfiro esperar 4 anos do que ter esse problema (aliás,é um dos grandes diferenciais da plataforma java para a .NET e ninguem no java vai abrir mão disso.). No meio tempo,se quer mesmo usar closures e operador + com bigdecimal basta usar groovy que até compila para .class …

C

Sergio,

Quanto ao comparativo entre INTEIROS e NUMEROS DECIMAIS , eu explicitei como estes contextos podem ser “mascarados” no BigDecimal da mesma forma que muitos contextos são mascarados na JVM… apenas mais um truque , que teria impacto identico ao exemplo dado em inteiros primitivos…

O que não dá para misturar é dizer que o a inclusão do invokedynamic inviabilisou a inclusao de qualquer outra alteracao na JVM… ou dá ?

Quantoa espera de 4 anos… se voce somar a quanto tempo closures poderiam ter sido incorporadas (ou pelo menos discutivas) a JVM… vai perceber que serão MAIS 4 anos… e não 4 anos…

Quanto a groovy compilar para .class não quer dizer muito… pois se for algo ao estilo do JRuby , estou dispensando.

S

chun:
Sergio,

Quanto ao comparativo entre INTEIROS e NUMEROS DECIMAIS , eu explicitei como estes contextos podem ser “mascarados” no BigDecimal da mesma forma que muitos contextos são mascarados na JVM… apenas mais um truque , que teria impacto identico ao exemplo dado em inteiros primitivos…

Não,não teria. É isso que estou tentando dizer.

Eu não disse isso.Aliás,acho que ninguem disse isso.

existem coisas como o file watch dog que fazem falta à anos (mais de 6) e só agora estão ai. O ponto que queria deixar claro
é que a ideia tem que amadurecer,pessoas têm que a implementar como o que ha e só depois essas mesmas pessoas serão chamadas a propor um padrão. Entenda que o fato de ser um padrão para todo o futuro do java é algo muito,muito, forte. E não se pode por algo apenas porque é bonito , da moda, ou inventado por alguem…o pacote de util.concurrent é outro exemplo
e até mesmo as coleções do java são um exemplo deste processo de amadurecimento ( o apache collections é anterior)

Portanto, não serão mais 4 anos. Serão apenas mais 4 anos :wink:
4 anos é muito tempo. Pode ser que até lá a Oracle tenha desmantelado o java… :twisted:
Mas pode ser que no java 8 sejam incuidas mais algumas coisas que tornaram a implementação de closures trivial no 9.
O que eu queria deixar claro é que ha processo de maturação necessário e que a não inclusão das coisas não é má vontade. É proteção.

C
  1. Poderia explicar o PORQUE não ? (Referente ao BigDecimal) , o que impediria eles de implementarem isto ?

2)Voce colocou : “Por isso o foco foi em adicionar invokedynamic” falando assim parece que o foco tem que ser apenas UM por versao…

  1. Em dias de hoje… todo esse protecionismo vai arruinar Java.
C

Não era a JVM da Apache que previa “features plugaveis” na JVM? O que permitiria expandi-la de forma organizada e daria a liberdade para qualquer um extender a linguagem java ?

Aproposito… saiu essa JVM ?

L

A ÚNICA coisa que me interessa pra “segurar” um pouco as pessoas no Java era uma maneira para não se precisar usar getters/setters, não tem, o demais pra mim é tudo firula.
:frowning:

Quem esta testando Ruby e/ou Scala, não vai voltar JAMAIS pro Java, até o Java 8, podem escrever, a maioria de nós que estamos nesse tópico já não vai trabalhar mais com Java.

Vou fazer questão de cotar isso no tópico do Java 8 rs

S

chun:
1) Poderia explicar o PORQUE não ? (Referente ao BigDecimal) , o que impediria eles de implementarem isto ?

Tecnicamente nada. Filosoficamente muito. É esse o ponto.
Com todas as gafes que o sistema numerico do java tem ,BigDecimal e Biginteger ainda sao um porto seguro.
Quando virar tudo a mesma coisa mais problemas vao acontecer.são esses problemas que têm que ser analizados para
ter a certeza que vale a pena. No groovy o bigdecimal é usado por default, mas a devisão força o arredondamento ( seja http://groovy.codehaus.org/Groovy+Math ) e ainda por cima o arredondamento mais danoso. É isso que vc quer por padrão no java ? quer seus calculos financeiros feitos assim ? E calculos cientificos ?
Java é usado para muitas coisas e algumas delas precisam de ter cuidado com BigDecimal.Se já é dificil educar os programadores agora ,imagine quando eles poderem fazer 1/3 …

Não.Se vc reler vc vai entender que estou falando em comparação como o bigdecimal. Invokedynamic (novo bytecode) tinha prioridade em cima de alterações do compilador. Vc sabe ha quanto tempo um bytecode novo foi incorporado à jvm ? vc imagina o que isso significa ? então sabe que é coisa séria. Muitos recursos são aplicados nisso.

Eu acho exatamente o contrário. Foi ele que colocou o java no mapa e foi ele que obrigou a microsoft a criar o .NET
e é ele que marca a diferença entre as duas plataformas. Para mim o respeito ao codigo legado é mais importante que novas features. E isto tb é importante para muitas empresas que entendem o que Produto de Software significa.
Experimente correr codigo .NET 1 em .NET 3 :twisted:

C

Sergio:

  1. A minha vontade não é colocar BIGDECIMAL por padrao… apenas facilitar as coisas… se voce analisar o ESCOPO consegue-se fazer algo descente sem todos estes impactos.

  2. Recursos em P&D a Sun aplica aos milhoes… nao eh motivo para focar em uma unica feature… acho que eh uma questão mais de protecionismo do que qualquer coisa.

  3. Protecionismo demais me cheira a “burrocracia”.

P

Luca, em algum lugar tem a lista dos brasileiros que mandaram propostas?

E sobre tudo isso que nao entrou, tambem sou meio conservador hoje em dia: deixem o Java simples, para ele nao acumular 100 mil features a la C++, e vamos inovar nas outras linguagens que tambem rodam sobre a JVM.

M

"

L

show!

L

Olá

Paulo Silveira:
Luca, em algum lugar tem a lista dos brasileiros que mandaram propostas?

E sobre tudo isso que nao entrou, tambem sou meio conservador hoje em dia: deixem o Java simples, para ele nao acumular 100 mil features a la C++, e vamos inovar nas outras linguagens que tambem rodam sobre a JVM.

Não sei da lista mas vi aqui muita gente reclamando e acho que eles não mandaram sugestão para o lugar certo na hora certa.

Eu também não gostaria de ver a linguagem Java muito modificada como foi o caso da introdução dos generics no Java 5. Entre outras coisas, cria dificuldades na homologação de novas versões na cabeça de gente que tem poder mas que não tem tempo para avaliar corretamente as vantagens de migrar. O switch aceitando Strings não influi nos sistemas atuais.

Mas gostaria de ver o Java evoluir através da inclusão de novas facilidades na API do tipo usa quem quer. Algumas das inclusões prometidas não virão. Uma coisa que não afetaria nenhum sistema em uso mas que seria bom para novos sistemas seria as novas facilidades do JMX. Acabei de verificar no blog do Eamonn McManus de 16 de junho de 2009 que não entrarão no Java 7. Ver http://weblogs.java.net/blog/2009/06/16/jsr-255-jmx-api-20-postponed

Daquela minha lista de inclusões/alterações na API,não estou certo do que realmente virá e o que ficará para o Java 237

[]s
Luca

M

"

S

marcosalex:
Uma diferença interessante no foco do Java é que a linguagem é projetada pra que seja fácil terceiros desenvolverem frameworks e componentes em cima.

O .NET a própria MS desenvolve seus componentes e te o framework completo, sem precisar de terceiros.

Cada lado tem suas vantagens e desvantagens. Mas acho que a Sun acaba saindo perdendo nessa, porque a maioria dos que desenvolvem no Java não gostam muito de usar componentes de terceiros porque temem que suas soluções sejam dependentes deste. E pra usar somente a ferramenta da Sun, acaba que a produtividade não fica tão grande, já que muita coisa que os outros tem pronta, você vai ter de fazer na mão.

Bom , na realidade isso é uma feature e não um defeito.
Sim, o SE,ME e EE não são completos. Isso é proposital.
Espera-se que a equipe monte uma plataforma de aplicação em cima disso. E ai cada empresa pode montar a sua e proteger os seus investimentos. O uso de api de terceiros é uma opção a montar a sua plataforma de aplicação mas com o detalhe do vendor lock-in.
Mas depende muito do tipo de aplicação. Um produto de software, por exemplo, não pode deixar a plataforma de aplicação na mão de api de terceiros, já um projeto on demand pode (é responsabilidade dos intervenientes pedirem que seja montada uma plataforma propria)

A microsoft já dá a plataforma de aplicação.E sim,isso é uma limitação.
Por exemplo, muita gente não compreende que ASP.NET não é comparável a JSP e sim a JSF.
Mas JSF é baseado na servlet API, em servlets, que vc pode usar directamente e fácilmente se quiser.
Ja no .NET vc pode usar handlers que são semelhantes a servlets,mas não ha pq quando vc tem o ASP.NET.

O nivel da microsoft é muito mais longe da tecnologia base e mais perto da gui porque pretende ser uma plataforma RAD.
Java não pretende ser RAD, pertende ser flexivel, expansivel e durável.

J

:arrow: “façam como os brasileiros”, quando eu digo que a gente cobra barato pra trabalhar com Java você ainda acham que estou de brincadeira, os Brasileiros são os melhores desenvolvedores do Mundo.

J

sergiotaborda:

Espera-se que a equipe monte uma plataforma de aplicação em cima disso. E ai cada empresa pode montar a sua e proteger os seus investimentos. O uso de api de terceiros é uma opção a montar a sua plataforma de aplicação mas com o detalhe do vendor lock-in.

Pergunto,

O MiddleHeaven framework futuramente, tende a ser um vendor lock-in ?

S

JavaLivros:
sergiotaborda:

Espera-se que a equipe monte uma plataforma de aplicação em cima disso. E ai cada empresa pode montar a sua e proteger os seus investimentos. O uso de api de terceiros é uma opção a montar a sua plataforma de aplicação mas com o detalhe do vendor lock-in.

Pergunto,

O MiddleHeaven framework futuramente, tende a ser um vendor lock-in ?

Sempre que você usa qualquer framework ou API nos seus projetos que não foi desenvolvida in house e/ou não é parte da JSE , JEE ou das outras edições padrão então, você já caiu no vendor lock-in. Deste ponto de vista sim.

Se você usa qualquer framework ou API que é opensource, então você pode pegá-lo e mantê-lo ( aquilo que se chama um fork). Claro que isso não é tão simples quanto parece, mas pelo menos não o deixará na mão. Desde ponto de vista não. Você não terá problemas com vendor-lock in. O MiddleHeaven tem licença BSD que é bastante flexivel.

L

Acho muito legais todas as novidades…

Coisas novas nos fazem acreditar que Java, como linguagem, não está morta.

Java como plataforma, IMHO, está cada vez mais certo como um bom caminho, principalmente com cada vez mais linguagens suportadas em cima da JVM.
Já como linguagem, torço por cada vez mais simplicidade, assim como temos visto em Groovy, Rails, Scala…

Pras aplicações web, torço também por não ter mais que esperar por váaarios segundos por um redeploy da aplicação. :stuck_out_tongue:

Abraços.

R

Olá:

Neste artigo Stephen Colebourne discute a sugestão de uma série de métodos utilitários para os pacotes java.util e java.lang baseado no Apache Commons Lang.

Grato,

T

Continuo lamentando a ausência de closures nessa nova versão :frowning:
Mas confesso que, assim como muitos, era uma coisa que eu nem sentia falta, pois não conhecia. Já tinha usado em Scheme uma vez, quando ainda não havia esse “hype” em cima de closures.

Bem vindo de volta, Marcio Duran :smiley:

M

"

T

Resumindo: não quer ficar “locked in”? Crie sua própria linguagem, ferramentas, frameworks, compiladores, tudo… e pelamordedeolz pare de choradeira e mimimi.
PRONTOFALEIDENOVO.

S

eu acho que o JAVA poderia ter uma forma de deixar o tipo byte unsigned… pq para comunicar com placas via udp, as vezes vc tem que enviar um valor que o tipo byte nao suporta… ai complica a vida

V

Evite ressuscitar tópicos. Esse era de 2009.

Mas concordo com vc. No mínimo tinha que ter funções que fizessem a promoção ou redução de tipos maiores para seus respectivos unsigned nas classes de Stream e na classe ByteBuffer (como ter na própria classe ByteBuffer o que a classe ByteBufferWorker que postei no GUJ faz).

L

Olá

Viva a diversidade de opiniões!

Eu por exemplo acho saudável ressuscitar tópicos que discutem temas ainda atuais e que não acabaram em trollagens. O Java 7 ainda não lançado mas que eu já estou usando depois de baixar em http://jdk7.java.net/preview/ (novas features em http://openjdk.java.net/projects/jdk7/features/ ), é um tema mais do que atual. Para mim foi bom trazer de volta todos os links aqui postados.

Quanto a sua pergunta, além da ótima resposta do Vini sobre os ByteBuffers, lembro que este tópico é uma antiga reinvidicação dos desenvolvedores Java como se pode ver pelo tanto de links que a gente encontra em http://www.google.com.br/search?q=java+unsigned

[]s
Luca

F

Achei bem interessante a mudança do switch ficou bem mais amigável usar o if era triste.
Quanto as demais mudanças eu ainda não entendi, pois do java tiro apenas o arroz feijão.
Muito bom o post

V

Excelente post.

A

Alguém encontrou a parte que fala (se é que fala) da substituição de verificação por null pelo caracter “?”, como acontece no Grails? Assim

Olhando aqui não encontrei nada a respeito.

M

Se não for o caso, torna-se irrelevante, dá para fazer assim:

O contrato de equals prescreve que qualquer chamada de equals com parâmetro nulo devolve falso, em outras palavras, NPE Free.

Andre Brito:
Alguém encontrou a parte que fala (se é que fala) da substituição de verificação por null pelo caracter “?”, como acontece no Grails? Assim

Olhando aqui não encontrei nada a respeito.

L

Evite ressuscitar tópicos. Esse era de 2009.

Mas concordo com vc. No mínimo tinha que ter funções que fizessem a promoção ou redução de tipos maiores para seus respectivos unsigned nas classes de Stream e na classe ByteBuffer (como ter na própria classe ByteBuffer o que a classe ByteBufferWorker que postei no GUJ faz).

Eu já implementei rotina de ponto flutuante em Java onde utilizava todos os 32 bits do int e todos os 64 bits do long, ignorando o sinal. No Java basta ignorar o sinal do tipo se tudo o que você quer é utilizar operações de bit.

Todos os números em Java (e em diversos hardwares) são guardados no formato “complemento de 2”, ou seja, cada posição de bit é um peso diferente e a soma total dos pesos dá o valor do número. Por exemplo, 0x80, que vem logo após 0x7f, é -128 e por aí vai.

Na VM que criei uso bytes em um ByteBuffer para guardar as instruções, e uso todos os 8 bits do byte.

O sinal só é necessário para operações aritméticas, mas nesse caso um tipo mais largo como int seria o mais indicado. Quem usa byte, geralmente só quer passá-lo via rede ou utilizá-lo para algo baixo nível.

L

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

Que nada. Closures são uma das coisas mais hypeadas nos últimos tempos, acho que quem acredita que isso é a solução para todos os problemas realmente não entende como funciona.

Closures nada mais são do que um objeto de pobre. Isto é, o ambiente léxico é como os campos de uma classe e o tal objeto tem apenas um método que não aceita argumentos. Não existe absolutamente nada que closure faça que não seja possível fazer com objetos.

Closure apenas simplifica o código em alguns casos, mas no Java, como eles não podem remover nada, acho que acabaria complicando ainda mais. Para tudo existiriam duas ou mais formas de se fazer.

Acho que seria melhor criar uma linguagem nova do zero ao invés de adicionar closure no Java.

M

"

V

Otima mudanças mesmo!

M

Concordo, acho que é mais um Hype. Uso lambdas no C# e Ruby e programo sem problemas no Java 6 sem elas. Programação funcional está hypeado como disse o Longino, contudo acho que tem seu valor. As expressões usadas no JPA seriam mais simples, enxutas, e legíveis até, se fossem escritas com lambdas, bem como a implementação do padrão Strategy, onde hoje usamos interfaces (ver Comparator).

Também acho que inseriram muito Syntactic sugar, como a notação diamante, uso de índice para coleções, verificação de nulo, etc, em outras palavras, uma adição de facilidades para diminuir o Boilerplate Code (e consequentemente o código).

Penso que a promiscuidade (não entendam mal) atual dos programadores com linguagens (ver dica do Pragmatic Programmers: aprenda uma linguagem por ano) faz com que haja uma pressão por mudanças e um medo de perder espaço. Eu por exemplo me identifico muito com Java mas não sou Evangelista ao ponto de ficar cego (como muitos fazem) e me entrego “aos prazeres” de outras linguagens, plataformas, soluções.

Resumindo, acho que os releases do Java EE, do 1.4 para o 5 e depois para o 6 foram muito mais substanciais que as mudanças no Java SE (que são boas, nunca disse o contrário), equiparáveis a mudança do Java SE 1.4 para o 5, mas pouco expressivo do 5 para o 6 e agora do 6 para o 7.

marcosalex:
Longino:

Que nada. Closures são uma das coisas mais hypeadas nos últimos tempos, acho que quem acredita que isso é a solução para todos os problemas realmente não entende como funciona.

Closures nada mais são do que um objeto de pobre. Isto é, o ambiente léxico é como os campos de uma classe e o tal objeto tem apenas um método que não aceita argumentos. Não existe absolutamente nada que closure faça que não seja possível fazer com objetos.

Também penso assim sobre Closures. Não vejo como a vida dos programadores mudariam tanto quando o Java suportar closures. Em algumas poucas situações você vai digitar algumas linhas a menos de código, em outras vai ficar um código um pouco mais legível, mas nada revolucionário.

Essa briga de recursos me lembra os tempos de VB x Delphi, onde uma delas incorporava algum recurso pouco usado e usava isso como marketing, então a outra incorporava o mesmo recurso e adicionava outro ainda mais obscuro pra inverter a situação. No final ficaram duas linguagens totalmente cheia de coisas que ninguém usa, poluídas e confusas. Até chegar uma nova geração de linguagens com o intuito de simplificar a vida do desenvolvedor.

Agora com .NET x Java estou vendo a mesma coisa, e já está cheio de linguagens muito mais simples vindo na sequência. E a fila continua andando…

M

Com essa nova versão do Java, vai sair uma nova certificação? Estou na faculdade e pretendo tirar minha primeira certificação. Devo tirar a SCJP 6 ou devo esperar a 7?

M

Galera boa tarde,

Aproveitando o tópico, alguém viu se saiu alguma solução como o FileSystemWatcher no java 7?

Abraço.

L

Bruno Laturner:
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…

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

É verdade, muita gente esqueci de fechar, é sempre bom dar uma mão ao programador.

Mas será que vai valer para conexões com BD também ??

M

As alterações são cosméticas, não tem relevância alguma. É uma total perda de tempo migrar para o java 7, prefiro aguardar o java 8, pois aí sim muda de figura.

M

São modificações pequenas, mais que vão ajudar bastante no tempo de implementação.

M

"

A

Previsão da certificação Java 7?

M

"

M

Não acredito que a certificação em java 7 seja lançada logo, normalmente a oracle leva algum tempo para definir o que será cobrado na prova.
Pessoalmente, não acho que tal certificação tenha valor, é só mais um produto disponibilizado pela oracle.

M

"

H

São só a Java 7, mas realmente tem muita Certificação “travada”. As Java EE 6 não estão disponíveis ainda.

P

Pessoal, tópico meio antigo, mas pintou algumas dúvidas, como vi algumas outras referências sobre os mesmos recursos, vou postar as dúvidas aqui.

Tente testar os códigos para os novos recursos, e os seguintes itens não consegui executar através do netbeans 7.2 e oracle java jdk 7 mais recente.

  • Elvis Operator e do Null-Safe Navigation : Não funciona, não reconhece o código.
  • Automatic Resource Management: Não reconhece o try com ‘()’, testei vários exemplos e nenhum funcionou.

Seriam recursos implementados somente na OpenJDK? OU São válidos também para a JDK oracle?

Aqui está com uma instalação do windows 7 nova, com jdk oracle 7 e consegui testar somente alguns exemplos.

V

Funcionam em qualquer JDK.

Verifique no Netbeans se seu projeto não está configurado para compilar em Java 6.

T

Vou dar uma olhada para ver se dá para confiar já… :frowning: :frowning: :frowning:

Criado 31 de agosto de 2009
Ultima resposta 16 de set. de 2012
Respostas 111
Participantes 57