Artigo Java Magazine 33 - Prepare-se para o Mustang

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo Publicado pela Java Magazine 33.

Esse artigo faz parte da revista Java Magazine edição 33. Clique aqui para ler todos os artigos desta edição

jm33.jpg

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.awtSystemTray 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).

A nova API java.text.Normalizer permite converter uma string Unicode para sua forma canônica, que evita ambigüidades. O padrão Unicode suporta representações múltiplas de muitos caracteres; por exemplo, "Á" pode ser representado pelo código único 0x00C1 (Á), ou pelo par de códigos 0x0041 (A) e 0x0301 (acento agudo combinável). A forma canônica decide por uma representação única, garantindo que strings que representam os mesmos caracteres sejam binariamente idênticas. Aplicações que exigem essa forma canônica incluem diversos padrões XML, assinaturas digitais, e os novos nomes de domínios internacionalizados (veja o tópico "Net: Nomes de domínio e URIs internacionalizados" na seção "Core").

Gerenciamento de layout: baselines e gaps

No AWT, o novo enum java.awt.Component.BaselineRasterizerBehavior permite determinar de que forma a baseline (linha de base) de um componente pode variar durante redimensionamentos (a baseline é a posição inferior do corpo dos caracteres, sem contar hastes inferiores ou "descendentes"). Pode-se forçar o componente a manter as baselines a uma distância fixa do centro, da origem, ou da altura do eixo Y.

O Swing acrescenta suporte à customização de gaps, com a nova classe javax.swing.LayoutStyle e o enum LayoutStyle.ComponentPlacement (gaps são as distâncias entre as bordas de dois componentes relacionados).

Ambas as APIs, para baselines e gaps, serão utilizadas principalmente pelas implementações de look-and-feels, para produzir layouts mais precisos, simulando os layouts nativos até o último pixel. Aplicações dificilmente precisarão utilizá-las diretamente, com poucas exceções – como gerenciadores de layout customizados e editores visuais de ferramentas de desenvolvimento.

Drag-and-drop

O suporte do Swing para drag-and-drop ficou flexível e mais fácil de programar. No pacote javax.swing, confira o enum DropMode, as classes TransferHandler.DropLocation e TransferHandler.TransferInfo; e novos métodos get/set para estas propriedades em JTable, JList, JTree e JTextComponent.

Melhorias em componentes Swing

As abas de JTabbedPane, ao invés de apenas ícones, texto ou HTML, poderão também conter componentes arbitrários, permitindo criar, por exemplo, interfaces gráficas como abas contendo botões. O recurso é implementado por "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?