Artigo Java Magazine 54 - A nova versão do Java 6 para aplicações ricas

A tecnologia do Java para desktop nunca ficou parada. Nesta coluna já examinamos melhorias na Swing, no desempenho da JVM, na funcionalidade do Java Web Start e outros fatores. Mas estas melhorias têm sido insuficientes. O Java obteve um sucesso apenas modesto para aplicações desktop em geral – embora seja bastante usado em alguns segmentos, como projetos que realmente precisam de GUIs ricas e portáveis entre várias plataformas, ou front-ends para aplicações corporativas. Mais grave é a situação do Java como plataforma para GUIs distribuídas via web: as applets foram varridas do mapa e não foram substituídas em massa por aplicações Swing, mas sim, por outras opções como Flash ou mesmo a tecnologia HTML renovada pelo AJAX.

A partir da JavaOne 2007, a Sun anunciou um contra-ataque: vários aperfeiçoamentos no JRE, que viriam resolver de um só golpe uma boa lista de reclamações históricas dos desenvolvedores que usam Java, especialmente com a Swing, para criar aplicações desktop. Esta promessa se tornou realidade, já estando disponíveis builds preliminares do “Java SE 6 Update N”. O release final estará pronto em agosto de 2008, portanto, este é um bom momento para começarmos a examinar esta atualização, que pode ser uma nova injeção de ânimo para o Java em um front que tem sido seu ponto fraco.

Problemas do Java para desktop

Começaremos fazendo uma revisão das dificuldades do Java no desktop, não só reclamando de tudo que está errado, mas procurando entender por que está errado. Esta seção nos ajudará a julgar se as melhorias do Update N resolvem o problema e também nos dará uma visão mais aprofundada dos problemas, não só do Java, mas também de outras plataformas modernas. (Em especial, a plataforma Microsoft .NET, que enfrenta muitos dos mesmos problemas discutidos aqui.)

Tempo de Carregamento

Um dos problemas mais perceptíveis de aplicações Java complexas é o tempo de inicialização. O administrador de um servidor de e-commerce não se incomoda em esperar um minuto ou dois para o boot de um cluster de servidor de aplicações paquidérmico. Mas para o usuário final de uma aplicação desktop, é irritante esperar até mesmo cinco segundos para carregar qualquer aplicação.

O tempo de carga é resultado da arquitetura de Virtual Machine do Java. Em uma aplicação nativa, os arquivos binários (como .exe e .dll no Windows) são estruturados de uma forma extremamente eficiente para determinada plataforma. Tanto o código quanto os dados são específicos para certa arquitetura de hardware & SO, e praticamente só precisam ser lidos do disco para a RAM[1]. Já os arquivos .class portáveis do Java precisam ser lidos, convertidos, e organizados (o layout em memória pode ser muito diferente do usado nestes arquivos). E depois, cada método será ou lentamente interpretado, ou compilado para código nativo – uma operação custosa, apesar de toda a avançada tecnologia de compiladores JIT dinâmicos como o HotSpot.

Alguns desenvolvedores se surpreendem ao ver que linguagens com runtimes menos sofisticados, como Perl, Python ou Ruby, não têm nenhum problema com tempo de inicialização. Mas isso ocorre devido à falta de desempenho destas linguagens, tipicamente interpretadas. É uma troca: o seu código Ruby pode começar a rodar imediatamente, mas tente escrever qualquer algoritmo complexo e você verá que o Java roda dezenas ou até centenas de vezes mais rápido. Se o tempo de inicialização é muito mais importante para você, experimente usar java –Xint, que executa a JVM em modo puramente interpretado. Para utilitários de execução breve, isso elimina o custo da compilação JIT e pode até melhorar o desempenho total.

Tamanho do JRE

O download do JRE pode ser um problema para quem distribui aplicações via web. O JRE 6.0 Update 3, por exemplo, tem quase 14Mb na versão internacionalizada para Windows. É quase 10 vezes maior que os 1,5Mb do Flash 9. Sem falar em HTML/AJAX, que não exige download algum.

Podemos dizer em defesa do Java que seu runtime não é grande demais: pelo contrário, é pequeno, para tudo que ele faz. Não há prova maior disso que compará-lo ao redistribuível do .NET 2.0, que mesmo evitando os custos da portabilidade, com seus 22Mb é quase 60% maior que o JRE (parte da diferença é justificada por algumas capacidades server-side, como ASP.NET).

"

ATENÇÃO! A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

Saiba como acessar este post através de Créditos DevMedia:

Assinatura de Créditos – Aqui este post custa R$ 1,47
Com esse plano você compra R$ 180,00 em créditos e ganha, em média, 80% de desconto no preço do post.  
Assine agora

Plano ocasional - Aqui este post custa: R$ 1,96 (assinante) ou R$ 2,45 (não-assinante)
Você compra um mínimo de R$ 60,00 em créditos e ganha, em média, 50% de desconto no preço do post.  
Compre agora

Plano conveniência – Neste plano este post custa R$ 4,90
Neste plano você compra somente um post, pagando seu preço sem desconto.  
Compre agora