Artigo Java Magazine 17 - GUIs Nativas com SwingWT

GUIs Nativas com SwingWT

Portabilidade e performance no desktop

A API Swing, que integra o Java 2 Standard Edition (J2SE) desde a versão 1.2, é talvez a parte mais controversa de toda a plataforma Java. Os desenvolvedores amam ou odeiam o Swing: amam por causa do poder da API e pela possibilidade de escrever aplicações complexas que rodam inalteradas em todas as plataformas de desktop do mercado; odeiam por causa da performance ainda inferior quando comparada à de aplicações nativas e pela falta de integração com temas de desktop.

O lançamento do IDE Eclipse aumentou essa controvérsia; o IDE adotou uma biblio­teca de componentes visuais alternativa, o SWT, que utiliza os componentes nativos sempre que possível, enquanto o Swing uti­liza apenas primitivas gráficas básicas da plataforma, sendo os componentes visuais escritos inteiramente em Java.

Alguns desenvolvedores viram o SWT como a solução para seus problemas, per­mitindo a construção de aplicações Java para desktop capazes de realmente com­petir no mercado com aplicações nativas. Outros viram no novo toolkit o perigo de fragmentar o universo Java, além da de­sagradável possibilidade de vir a ter que aprender mais uma API e reescrever seus componentes personalizados.

O SwingWT oferece a possibilidade de reunir as vantagens das duas bibliotecas de componentes visuais. Implementa um “clone” da API Swing, utilizando os componentes do SWT. Então, com o SwingWT haveria o trabalho de apenas recompilar componentes e aplicações, originalmente escritas em Swing, para usufruir das vantagens de performance e integração com o desktop nativo do SWT. Essa possibilidade vem chamando a atenção do mercado, mas devemos ter em mente que o SwingWT ainda está em beta, portanto o seu uso pode exigir a reescrita de partes das aplicações, ou mesmo a con­tribuição de correções de bugs ao projeto, como veremos neste artigo.

No final das contas, o SwingWT exempli­fica um dos grandes benefícios do software livre: permitir a exploração de soluções di­ferentes daquelas oferecidas pelos grandes fornecedores.

Utilizando o SwingWT

Converter uma aplicação Swing para SwingWT é mera questão de modificar todas as referências aos pacotes java.awt e javax.swing para swingwt.awt e swingwtx.swing, respectivamente, e depois recompilar a aplicação. É claro que as classes cor­respondentes do SwingWT devem estar presentes no classpath da aplicação, assim como as classes e bibliotecas dinâmicas da implementação do SWT específica para o seu sistema operacional. É importante lembrar que, embora o SwingWT seja es­crito inteiramente em Java, o SWT contém código nativo. Além disso, mesmo a parte do SWT escrita em Java não é portável, pois depende das APIs nativas utilizadas.

Caso sejam usados componentes visu­ais de terceiros, estes também devem ser editados e recompilados para que sejam compatibilizados com o SwingWT. Ou seja, não é possível misturar, em uma mesma aplicação, componentes Swing originais e componentes SwingWT. Já a mistura de componentes SwingWT com componentes SWT é possível. Todo componente Swin­gWT é também um componente SWT; ape­nas é enxergado a partir de uma interface diferente (numa aplicação do design pattern Adapter). Basta chamar o método getPeer() de um componente SwingWT para obter o componente SWT correspondente. Isso significa que o SwingWT pode ser utilizado para facilitar a transformação de uma aplicação Swing em um plug-in para o Eclipse ou em um componente para o novo RCP do Eclipse Consortium (veja o quadro "Rich Client Framework")

Componentes não-visuais escritos para o Swing (layout managers e modelos de do­cumentos – subclasses de AbstractListModel, AbstractDocument, AbstractTableModel – entre outros) também precisam ter seus fontes editados e recompilados. E componentes equivalentes do SWT podem ser utilizados diretamente, mas através dos métodos do componente SWT subjacente, não dos mé­todos que emulam a API Swing." [...] continue lendo...