[quote=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…
[/quote]
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 
e só agora a temos)
e só agora a temos)
