Artigo Java Magazine 03 - Java Livre

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

Java e GTK+

Uma alternativa ao Swing

Usando o toolkit livre GTK+ para criação de aplicações Java visuais com performance nativa

Nos seus primórdios acreditava-se que Java seria a plataforma padrão para o desenvolvimento de aplicações no desktop, ocupando o papel que então era do Windows. O tempo passou, e o Java não conseguiu realizar o seu potencial nesta área. Alguns culpam a Microsoft – que “sabotou” o Java ao criar uma versão da tecnologia que rodava apenas no Windows – mas a verdade é que o próprio Java possui deficiências que o levaram a ocupar com destaque, pelo menos até hoje, apenas o servidor e não o cliente.

Neste artigo apresentamos como o desenvolvedor Java pode utilizar o toolkit GTK+, o mesmo utilizado pelas aplicações GIMP, Gnome e Mozilla, para criar aplicações gráficas multiplataforma e com performance comparável a soluções nativas. Mas antes, você pode ver no Quadro "Por que o Swing é lento" o motivo do Java não ter “pego” ainda no desktop.

Por que o Swing é lento?

Originalmente, o Java fornecia o toolkit AWT para a criação de aplicações gráficas. O AWT era uma camada Java para os objetos gráficos nativos de cada plataforma, mas restringia-se apenas aos objetos que existiam em todas as plataformas suportadas, a saber Windows, MacOS e X Window (Unix e Linux). O resultado final era um toolkit muito pobre, sem objetos como sliders, abas, grids e tantos outros que os desenvolvedores consideravam indispensáveis.

Pior do que isso, o AWT não se comportava do mesmo jeito em todas as plataformas, porque um botão ou uma caixa de texto do Windows, por exemplo, não se comportam da mesma forma que seus equivalentes no MacOS ou X Window. O resultado levou a uma piada popular parodiando o slogan da Sun para o Java: “Write Once, Debug Everywhere” ("Escreva uma vez, depure em todos os lugares").

Com o Java 2, a Sun decidiu dar o status de padrão a um novo toolkit: o Swing, rico em componentes e escrito inteiramente em Java (utilizando apenas as primitivas gráficas e de janelas da plataforma, ainda fornecidas pelo AWT), e garantindo a compatibilidade multiplataforma das aplicações gráficas em Java. Mas o preço a pagar foi alto: qualquer aplicação Swing, mesmo um simples “Hello World”, é visivelmente mais lenta do que o equivalente escrito com ferramentas nativas, como Delphi, Visual Basic, QtDesigner, Glade ou Hypercard.

Em parte, o caráter interpretado dos bytecodes Java explica a lentidão do Swing – rotinas gráficas são onde se costuma ter código assembly escrito à mão. Mas o grande culpado é o próprio projeto (design) do Swing. Ele é escrito “by the book”, de modo excessivamente acadêmico, seguindo todas as boas práticas de orientação a objetos. Isso gera um grande overhead de troca de mensagens, criação e destruição de objetos temporários, e acúmulo de pequenos objetos aguardando pelo coletor de lixo, o que explica a grande demanda de memória de uma aplicação Swing típica.

Solução: de volta ao código nativo

Um toolkit gráfico “menos OO” (tal qual nossos projetos físicos de bancos de dados relacionais, que são freqüentemente denormalizados), e utilizando código nativo nos pontos cruciais, poderia dar ao Java desempenho comparável às soluções inteiramente nativas, mas ainda assim preservando o caráter multiplataforma da tecnologia.