Finalmente temos algo que podemos chamar de Java 7. Embora com muito atraso e relutância da Oracle em liberar esta versão para o público (já que a liberação é dirigida a desenvolvedores ) aqui temos a versão mais recente da tecnologia Java.

O Java 7 traz algumas alterações na linguagem Java,  algumas alterações na JVM e algumas API novas. Além disso temos a primeira alteração no bytecode desde sempre. Podemos dizer que o tema do Java 7 é “Criar caminho para o Futuro” (leia-se Java 8 e 9). Como alterações na Linguagem temos : Swicth com Strings ,melhor inferência de tipos com operador diamante e alterações para invocação de var-args , melhores literais para números,  base binária e melhor suporte a tratamento de exceções (multi-catch , re-throw e try-with-resources) e suporte a unicode 6.0.  Para as API temos a nova API de processamento paralelo Fork-Join  e a nova , muito aguardada , FileSystem API (parte do novo pacote de IO:  NIO.2) .Existem também alguns melhoramentos na API java.util.Locale para  internacionalização como a nova enum Locale.Category que permite distinguir objetos Locale para display e para formatação. A NIO.2 traz também suporte a mais protocolos de comunicação como SCTP , SDP entre outros. A alteração no bytecode é a nova instrução invoke dinamic que traz consigo a nova API de manipulação de métodos. Além disso muitas melhorias na renderização. A lista completa de mudanças na pagina de release da Oracle

Não vou exemplificar cada alteração existem muitos sites sobre isso. Quero, em vez, me debruçar sobre  as causas e consequências das alterações.

Switch com Strings. Esta funcionalidade é a mais perigosa de todas. Não vai ajudar a escrever programas melhores já que vivemos escrevendo programas sem ela ha 15 anos. Adicionar esta capacidade só vai ajudar a cria Programas Orientados as Strings (POS) ou pior, programas orientados a gambiarra (POG). Uma discussão interessante sobre switch e sua historia aqui. Mas o objetivo desta funcionalidade não é melhorar o Java. Esta era uma requisição de melhoria desde o java 1 que não viu a luz do dia devido ao problema associado à função de hash usada na classe String que foi modificada e melhorada ao longo do anos. É que, para isto funcionar, é necessário usar a função de hash para transforma o switch de string em switch de int que é o que realmente funciona eficientemente, mas para isso o resultado do hash tem que ficar hardcoded no .class. O Java 7 deu este passo estabelecendo que a implementação de hashCode do String não irá mudar mais. Mas será que não ? Eu por mim vou continuar não usando Strings para este tipo de coisa. Aliás uma regra bem válida do Efective Java.

Melhorias na inferência de tipos. O operador diamante é bem vindo já que nos livra de repetir um monte de assinaturas de tipo. Para quem já escreveu mapas de coleções sabe do que estou falando. Além disso usar tipos genéricos em var-args não causa mais um aviso do compilador.  Nada do outro mundo para o programador, mas o trabalho que o compilador faz para inferir os tipos e , no seu melhor, evitar erros, é extraordinário. Uma alteração direcionada a nos fazer escrever menos respondendo às criticas que o java é muito verborraico.

A possibilidade de escrever números em base binária é relativamente interessante. Útil se você mexe com protocolos/arquivos binários. A nova possibilidade de separação de algoritmos com underline ajuda bastante a formar os bytes ou as palavras. Uma mudança à primeira vista estética, mas que é direcionada a usar java como uma linguagem de “baixo nível” para ler e escrever binário.

A grande alteração da linguagem são as novas funcionalidades relacionadas ao bloco try-catch. A primeira é a possibilidade de capturar multiplas exceções de um catch só. Isto ajuda a escrever menos blocos de código e ajuda a seguir o principio DRY (Don’t repeat yourself – Não se Repita). Contudo criaria um problema caso você pense em relançar a exceção.  A inferência de tipos entre em jogo aqui também. Ao relançar a exceção o compilador sabe fazer o traking de quais exceções são possiveis dentro do try e portanto quais são possiveis para relançamento.

A outra mecânica que se aproveita do relançamento é o novo try-com-recursos que é uma forma de trabalhar com recursos “fecháveis”. A nova instrução toma conta de chamar o .close no momento certo e tratar as exceções que são lançadas no close.   É um problema quando você acessa o banco, dá erro no resultset você captura e fecha a conexão, mas ai dá erro no fechar da conexão. A exceção que você recebia era a que aconteceu no close e não a que aconteceu no resultset. Isto era realmente um problema e se você quisesse controlar isto. Agora, o java 7 modificou essa regra – desde que use o try-com-recursos  – em que a exceção lançada é a exceção original, e a excação secundária (chamada de exceção suprimida) é adicionada ao stackstrace de forma “paralela” usando os novos métodos na class Throwable addSupressed e getSupressed. O controle de exceção ficou ainda mais robusto.

isto é importante porque é usado no URLClassloader. Este é o classloader mais utilizado que não tinha uma semantica de fechamento, e agora que tem, sem um mecanismo robusto como o try-com-recursos , continuaria dando memory-leaks. A sintaxe não é a mais intuitiva (estão planejadas melhorias para o java 8), mas é uma instrução de controle muito importante e que faltava no arcenal.

O tema do Java 8 será “Multicore” e o do Java 9 “Cloud”.

Para multicore dar certo o fork-join é um framework necessário. Existiu muita polemica se seria util lançar este framework sem lançar closures (lambdas), mas acabou saindo. Lembrar que esta versão do java é mais para desenvolvedores do que usuários e em particular para desenvolvedores que desenvolvem mecanismo em cimado java (como quem desenvolver as ‘vm’ de jruby, scala , etc…) . Com a liberação “adiantada” estas equipes têm mais tempo para se preparar para o mundo com lambdas do java 8.

Para o cloud dar certo, além do multicore, é preciso abstrair o sistema de arquivos. Servidores de aplicação poderão tirar partido disto. A nova API de Filesystem permite trabalhar não apenas com discos da máquina, mas criar sistema virtuais de arquivos , por exemplo, acessar um zip como se fosse uma pasta. Isto é uma tendencia e era aguardado ha muito tempo ( aliás eu já tinha abordado este assunto de arquivos virtuais no MiddleHeaven). Mas API que fará ainda mais diferença – especialmente para criadores de ferramentas e servidores –  é a API WatchService que permite registrar listeners para escutar quando arquivos são modificados, incluídos ou excluídos. Hoje isto é feito com threads e timers, mas com a nova API estaremos ligados diretamente ao sistema operacional que avisará a API quando algo mudar e a API nos avisará a nós. Espero que as próximas versões de servidores de aplicação se baseiem nestas features.

Resta falar sobre o invoke dynamic. Esta instrução do bytecode permite que se invoque um método sem que se saiba qual a sua implementação. A implementação do método será pesquisada em runtime. É um mecanismo bem complexo que permite criar links dinâmicos com métodos em runtime. Isto é ideal para linguagens como groovy e ruby que permitem chamar métodos em classes como se eles lhes pertencessem mas na realidade não estão definidos na classe (  e sim em alguma outra classe ). Esta instrução é orientada a simplificar a vida de quem tem que implementar as vm das linguagens dinâmicas e com isto tornar a JVM realmente poliglota.

A API Java foi incrementada para poder manipular métodos de forma programática. Isto é interessante porque é agora possível criar operações de currying e outras coisas interessantes da programação orientada a funções mesmo ainda sem lambdas.

À parte da swicth de strings que navega contra a maré o resto das alterações é bastante poderosa. O ponto é que toda esta capacidade é em potencial e não muito “prática” ainda. É mais ou menos como o generic do java 5, demorou um tempo até que as pessoas se habituassem e começassem a fazer coisas interessantes com a ferramenta. O Java 8 promete uma mega alteração da forma de programar em java, e o 9 uma mega alteração na forma como entendemos JEE  , mas o Java 7 lança as bases e traça algumas direções dando ferramentas para aumentar a eficácia dos códigos e o alargamento da base de linguagens que rodam na JVM.

Se começasse um projeto novo hoje, muito provavelmente usaria java 7, não pelo que ele traz de novo, mas como preparação para o java 8 que, se tudo correr bem, irá ver a luz do dia em 2013.