Esse artigo faz parte da revista Java Magazine edição 33. Clique aqui para
ler todos os artigos desta edição
Clique aqui para ler esse artigo em
PDF.
Prepare-se para o Mustang
Explorando Todas as Novidades do JSE 6.0
Conheça todas as melhorias e novidades da próxima versão da plataforma Java Standard Edition, com lançamento final previsto para o meio de 2006
Osvaldo Pinali Doederlein
Não passou muito tempo desde o release de produção do J2SE 5.0 (Tiger) – 14 meses no momento em que escrevo – e o primeiro beta do JSE 6 (Mustang) já está disponível com o release final previsto para o início do segundo semestre deste ano. Esta velocidade pode assustar os desenvolvedores mais preocupados com a estabilidade da plataforma e com a curva de aprendizado que acompanha novas versões. Mas não há motivo para preocupação, pois ao contrário do Tiger o Mustang não é "revolucionário"; em especial, não introduz nenhuma novidade na sintaxe da linguagem Java.
Pelo contrário, o Mustang é uma atualização mais suave. Temos melhorias importantes de implementação, como novas otimizações do HotSpot – mas estas, como de costume, são transparentes, não exigindo alterações de código. Há APIs completamente novas, como a JSR-223 (javax.script) e a JSR-269 (javax.annotation), porém são a minoria, e são bastante especializadas. Há muitas atualizações incrementais, que adicionam algumas classes ou métodos a APIs existentes como o JDBC ou o Swing. Finalmente, temos APIs que só agora foram integradas à plataforma JSE, mas que já estavam disponíveis como extensões ou na plataforma JEE, como é o caso de diversas APIs de XML e web services,.
Em comparação com o Tiger, o Mustang realmente tem um foco maior em melhorar, corrigir, integrar e aperfeiçoar o que já existe (veja o quadro "Versionamento e evolução do Java SE"). Por outro lado, a ausência de novidades bombásticas (como os tipos genéricos do Tiger) não significa que o Mustang seja uma atualização trivial, um "J2SE 5.1 disfarçado". Melhorias incrementais também podem ter um alto impacto quando somadas e combinadas. Em especial, várias das novas APIs "não tão novas" do Mustang, além de meramente embutidas no JRE, foram atualizadas para dar suporte a um modelo de programação simplificado, dirigido por anotações.
Neste artigo, apresentaremos as novidades do JSE 6, no ponto em que se encontra na especificação Early Draft Review (dezembro de 2005) e na implementação Beta 1 (janeiro de 2006); veja links. Para facilidade de consulta, seguimos a ordem de apresentação de itens da especificação. Mas o objetivo é começar a partir do ponto em que a especificação termina – comentando mais à fundo os itens mais relevantes e interessantes, mencionando detalhes de implementação que já pudemos observar, ilustrando novidades com exemplos, enfim, tornando a especificação mais clara e concreta.
A especificação do JSE 6.0, a JSR-270, também referencia uma série de outras JSRs, que iremos indicar neste artigo. De uma maneira geral, as funcionalidades mais volumosas ou complexas, como APIs totalmente novas, exigem uma JSR à parte. Já os itens mais simples, como alterações pontuais em APIs existentes, são especificados na JSR raiz.
Features: Client (Desktop e GUI)
O grupo de recursos voltados a aplicações clientes compreende melhorias em Java 2D, AWT, internacionalização (I18N) e Swing. Inclui novidades importantes como acesso ao System Tray e novas opções de modalidade de diálogos.
Suporte à geração de GIF
A API javax.imageio já suportava vários formatos de imagem (JPEG, PNG, BMP, WBMP e GIF), mas até o J2SE 5.0 o suporte ao formato GIF era somente para leitura. Esta restrição não era de ordem técnica, e sim legal, pois o GIF era coberto por uma patente da CompuServe (empresa posteriormente adquirida pela Unisys). (Para ser preciso, a patente cobria a compressão LZW usada pelos arquivos GIF, entre outros formatos.)
Após 20 anos, em junho de 2004, essa patente expirou, permitindo o uso irrestrito do formato GIF. É uma boa notícia para quem desenvolve aplicações web que precisam gerar gráficos nesse formato (ex.: com o JFreeChart), pois o GIF ainda é muito popular. Por outro lado, já não é mais tão atraente quanto foi no começo da Web, tendo sido amplamente superado por formatos mais modernos como o PNG.
O suporte à criação de GIFs não exige mudanças de API, pois a javax.imageio abstrai a maior parte das diferenças entre formatos, através do uso de nomes simbólicos e de plug-ins que implementam interfaces genéricas. Para criar um GIF no JSE 6, escreve-se código como:
RenderedImage image = ...;
ImageIO.write(image, "gif", new File("imagem.gif"));
Integração com o desktop
A nova API java.awt.Desktop possibilita a execução de aplicações nativas registradas pelo gerenciador de desktop (ou área de trabalho) do sistema operacional. Por exemplo, o método browse(URI) abre uma URI usando o navegador web default do sistema, e o método open(File) abre um arquivo com a aplicação associada ao tipo do arquivo (por exemplo Word para .doc ou OpenOffice.org Calc para .ods).
As novas APIs de java.awt – SystemTray e TrayIcon – dão acesso ao "System Tray": aquela área, geralmente no canto da tela, com ícones de aplicações que funcionam em modo minimizado ou sem uma janela principal.
Telas de "Splash"
Muitas aplicações mais pesadas apresentam telas de splash durante sua carga. Esta tarefa agora é automatizada pela própria JVM, com o switch -splash:arquivo, ou em jars, editando o arquivo META-INF/MANIFEST.MF conforme este exemplo:
Manifest-Version: 1.0
Main-Class: AplicacaoMain
SplashScreen-Image: splash.gif
A exibição do splash é instantânea, pois é feita pelo "launcher" nativo (como o java.exe do Windows), antes da inicialização da JVM. Para customizar o splash, usa-se a nova API java.awt.SplashScreen. Esta API só dá um acesso de baixo nível ao splash: pode-se fechá-lo, mudar seu tamanho e posição, ou alterar a imagem do splash através de um Graphics. O splash não é um Component, e é fechado automaticamente quando a primeira janela AWT ou Swing for criada, o que não permite utilizá-lo para tarefas além de oferecer algum retorno ao usuário que espera a inicialização de uma aplicação.
Modalidade de diálogos
O suporte do AWT a diálogos modais (que bloqueiam a aplicação enquanto o usuário não fecha o diálogo) sempre foi muito restrito, bloqueando o acesso a todas as demais janelas da aplicação. Há muitos casos que exigem um comportamento diferente, como janelas de help on-line feitas com o JavaHelp: se alguma caixa de diálogo modal estiver sendo exibida, não podemos consultar o help, inclusive o da própria caixa de diálogo!
Tais limitações de modalidade são resolvidas pelo JSE 6, com os novos enums no java.awt, Dialog.ModalityType e Dialog.ModalExclusionType; e em Dialog através de novos construtores e métodos get/set para estas propriedades de modalidade.
Internacionalização
Os novos pacotes java.text.spi e java.util.spi definem Service Provider Interfaces (SPIs) para acrescentar novas localidades (locales) ao JRE, suportando opções de formatação de números, valores monetários e datas, ordenação de strings e fusos horários. Com estas SPIs pode-se customizar o comportamento de classes como java.util.DecimalFormat e java.text.Collator.
Uma exceção importante é que as SPIs não incluem suporte a calendários. Isto porque a interface java.util.Calendar foi mal projetada, sendo inadequada à definição de outros tipos de calendários além do gregoriano. É decepcionante, pois um dos engenheiros de internacionalização da Sun havia anunciado o suporte ao calendário imperial japonês no Mustang, além de outros calendários (como Hijri ou Persa) em releases futuros[1]. Pelo que parece, a Sun tentou usa a SPI para implementar o calendário japonês, mas não obteve bons resultados. A especificação determina que será preciso esperar por uma nova API para datas e horas. Isso confirma o conceito popular sobre as APIs temporais do JSE de que são mal elaboradas.
Também há novidades em java.util.ResourceBundle, entre elas o suporte a um formato de arquivo alternativo em XML, controle de cache, estratégias customizáveis de localização, definição de bundles por classes não-públicas, e em geral uma arquitetura mais aberta e plugável para todo o processo de carregamento de bundles. Estas melhorias serão críticas para aplicações com necessidades pesadas de internacionalização, como sistemas de gerenciamento de conteúdo (CMS).
...
