O GWT Toolkit: Crie front ends JavaScript poderosos usando Java

O GWT Web Toolkit, anteriormente conhecido como Google Web Toolkit, é um conjunto de ferramentas de desenvolvimento para construir e otimizar aplicativos complexos baseados em navegador usando a linguagem de programação Java.

O que torna o GWT não “mais uma ferramenta Java para escrever aplicativos web”, é o fato de que o coração do kit de ferramentas é um compilador que converte Java em JavaScript (assim como HTML e CSS), permitindo que os desenvolvedores escrevam aplicativos web front-end enquanto aproveita todos os pontos fortes do Java.

É ainda mais fácil usar uma combinação de Java e JavaScript, pois o GWT inclui uma arquitetura de interoperabilidade robusta para interface com a plataforma web. Assim como a Java Native Interface (JNI) permite que a Java Virtual Machine (JVM) chame rotinas específicas da plataforma (por exemplo, para acessar recursos específicos de hardware ou usar bibliotecas externas de outras linguagens), o GWT nos permite escrever a maior parte de um aplicativo em Java e, se necessário, usar uma API da Web específica ou aproveitar as bibliotecas JavaScript existentes para “tornar-se nativo” e pular para o JavaScript.

O GWT nasceu como um produto do Google, mas passou para código aberto no final de 2011 e hoje é lançado sob a Licença Apache (Versão 2) sob o nome GWT Open Source Project . Ele é gerenciado por um comitê diretivo com representantes de várias empresas, incluindo Google, RedHat, ArcBees, Vaadin e Sencha, além de desenvolvedores independentes da comunidade.

GWT no passado e no futuro

O Google Web Toolkit foi lançado pela primeira vez em 2006. Ele foi criado como uma ferramenta para ajudar os engenheiros do Google a desenvolver seus aplicativos complexos baseados em navegador, como AdWords, Google Wallet e Google Flights, e, mais recentemente, está sendo usado no centro de Aplicativos Planilhas Google e Caixa de entrada.

Em 2006, os navegadores (e interpretadores JavaScript) estavam longe de ser padronizados. O código front-end era lento, cheio de bugs e difícil de usar de forma confiável. Havia uma falta quase total de bibliotecas e frameworks de alta qualidade para desenvolvimento web. Por exemplo, jQuery não existia até este ano. Assim, para poder desenvolver aplicativos da web em larga escala, os engenheiros do Google decidiram aproveitar as ferramentas e competências existentes. Java era a linguagem mais adequada às suas necessidades, sendo bem conhecida e perfeitamente integrada a IDEs, como Eclipse, e assim o Google Web Toolkit começou sua vida.

O objetivo era mais ou menos esconder as diferenças entre os navegadores e encapsular os truques necessários para escrever JavaScript eficiente dentro de um compilador Java, deixando os desenvolvedores livres da tirania das tecnicalidades do navegador.

É claro que, na última década, a web mudou; os navegadores tornaram-se mais rápidos e convergiram para os padrões de implementação, e muitos frameworks e bibliotecas front-end incríveis foram desenvolvidos, incluindo jQuery, Angular, Polymer e React. Portanto, a primeira pergunta que você pode fazer naturalmente é: “O GWT ainda é útil?”

Em uma palavra: Sim .

No contexto do desenvolvimento web moderno, direcionar os navegadores é inevitável e o JavaScript se tornou a língua franca dos aplicativos front-end. Mas é claro que diferentes ferramentas e linguagens são mais adequadas para diferentes tarefas. O GWT, juntamente com um punhado de projetos semelhantes, visa direcionar os navegadores sem restringir os desenvolvedores ao uso de JavaScript.

O desenvolvimento e emprego de ferramentas “compile-to-the-web” como o GWT serão, num futuro próximo, facilitados pelo chamado grupo WebAssembly do World Wide Web Consortium. Não há apenas um vasto espaço para ferramentas que compilam para JavaScript, mas essa abordagem pode preencher uma necessidade real em contextos que vão desde descarregar parte da computação para navegadores, reutilizar código e bibliotecas existentes, compartilhar código entre back-end e front-end , empregando competências e fluxos de trabalho existentes e aproveitando recursos de diferentes linguagens (por exemplo, tipagem estática no caso do GWT).

O Projeto GWT deverá lançar a versão 2.8 em breve, e a versão 3.0 está em desenvolvimento, com grandes melhorias em andamento:

• interoperabilidade reinventada com JavaScript
• compilador melhorado (quase totalmente reescrito)
• suporte Java de última geração (por exemplo, lambdas)

Na verdade, a maioria dos recursos do GWT 3.0 já está disponível no repositório público do Git. Basta dar uma olhada no trunk, aqui e compilar o GWT seguindo a documentação aqui.

A Comunidade GWT

Desde que o GWT se tornou open source em 2011, a comunidade assumiu um papel fundamental na evolução do projeto.

Todo o desenvolvimento acontece no repositório Git hospedado em gwt.googlesource.com e todas as revisões de código são feitas em gwt-review.googlesource.com. Nestas páginas, qualquer pessoa interessada no desenvolvimento do Toolkit pode contribuir e ver no que a comunidade está trabalhando. Durante os últimos anos, a porcentagem de novos patches de não Googlers aumentou de cerca de 5% em 2012 para cerca de 25% no ano passado, confirmando o envolvimento crescente.

Este ano, a comunidade se reuniu para algumas grandes reuniões nos EUA e na Europa. O GWT.create, organizado pela Vaadin, foi realizado em Munique, Alemanha e Mountain View, Califórnia, em janeiro, e contou com mais de 600 participantes de dezenas de países. No dia 11 de novembro, em Florença, Itália, realizaremos a segunda edição do GWTcon, uma conferência GWT voltada para a comunidade que estou ajudando a organizar.

Para que serve o GWT?

Uma pesquisa anual sobre o kit de ferramentas do GWT, lançada pela Vaadin, discute a evolução do desenvolvimento do GWT, como os desenvolvedores se sentem sobre o kit de ferramentas, o que é bom, o que é ruim e assim por diante. Essa pesquisa também nos permite entender para que o Toolkit está sendo usado, como a comunidade de usuários está mudando e as expectativas que os desenvolvedores têm para o futuro do toolkit.

O Relatório do Futuro do GWT para 2015 pode ser encontrado aqui e deixa claro que o GWT é muito popular para a construção de aplicativos da web em larga escala. Por exemplo, na página 14, ele declara: “A maioria dos aplicativos são aplicativos de negócios com muitos dados e com os quais se trabalha por muitas horas por dia”.

Como esperado, é fácil concluir que o ambiente natural para o GWT é o campo de aplicações web de larga escala, onde a manutenção do código é importante e grandes equipes se beneficiam da estrutura da linguagem Java.

Por outro lado, olhando para os benchmarks de código gerado pelo GWT (por exemplo, no keynote da conferência GWT.create do ano passado, nas páginas 7, 8 e 11) é fácil ver que, em termos de desempenho e tamanho do código, o JavaScript compilado é incrivelmente impressionante. Se usado corretamente, o desempenho obtido é comparável ao melhor JavaScript escrito à mão. Como resultado, é realmente viável empregar o GWT para portar bibliotecas Java para a web.

Isso ilumina outro cenário ideal para o GWT. O ecossistema Java está repleto de bibliotecas de alta qualidade que não possuem contrapartida pronta para uso em JavaScript. O compilador GWT pode ser usado para adaptar tais bibliotecas para a web. Em outras palavras, o GWT nos permite misturar bibliotecas disponíveis em Java e JavaScript e executá-las no navegador.

Essa abordagem pode ser vista no desenvolvimento do PicShare, onde mostramos como várias bibliotecas Java geralmente não consideradas para a web (NyARToolkit por exemplo) podem ser portadas para o navegador usando GWT e combinadas com APIs web, incluindo WebRTC e WebGL, para obter uma ferramenta de Realidade Aumentada totalmente baseada na web. Tive o orgulho de apresentar o PicShare na conferência GWT.create 2015 em janeiro passado.

Sob o capô: transformando Java em JavaScript

O GWT Toolkit é um conjunto de ferramentas moderadamente complexo, mas qualquer um pode começar a usá-lo em um instante, graças a uma integração surpreendentemente fácil de usar com o Eclipse.

Criar um aplicativo simples com GWT é relativamente fácil para qualquer pessoa com experiência em projetos de desenvolvimento Java. Mas para entender o que “realmente está acontecendo”, vale a pena analisar os principais componentes do kit de ferramentas:

• Transpilador de Java para JavaScript
• Ambiente Java Runtime Emulado
• Camada de interoperabilidade

Compilador de otimização do GWT

Uma descrição detalhada de como o compilador funciona se torna altamente técnica bem cedo, e não precisamos nos aprofundar tanto, mas vale a pena examinar alguns dos conceitos gerais.

A primeira coisa a entender é que o GWT compila Java em JavaScript por tradução no nível do código-fonte. Ou seja, a fonte Java é traduzida ( transpilado é o termo técnico) para JavaScript. Isso contrasta com ter algum tipo de Java Virtual Machine escrito em JavaScript, que executa bytecode Java. (Isso é realmente possível e é a abordagem usada pelo Doppio, mas não é como o GWT funciona.)

Em vez disso, o código Java é dividido em uma árvore de sintaxe abstrata (AST) que representa os elementos sintáticos do código. Ele é então mapeado para um AST Javascript equivalente (e otimizado), que é finalmente convertido de volta ao código JavaScript real.

Pesar os prós e contras da transpilação está longe de ser o objetivo deste post, mas deixe-me observar que com esse método, o GWT pode alavancar diretamente os serviços de coleta de lixo do interpretador JavaScript, juntamente com quaisquer outros recursos nativos do navegador.

Existem algumas partes complicadas, é claro. Por exemplo, JavaScript tem apenas um tipo numérico, que não pode conter o tipo inteiro long de 64 bits do Java, então os tipos long requerem algum tratamento especial por parte do compilador. Além disso, a tipagem estática Java não tem significado direto em JavaScript, portanto, cuidados especiais devem ser tomados para manter, por exemplo, operações de typecasting equivalentes após a transpilação.

Por outro lado, uma vantagem facilmente apreciada da transpilação é que o GWT pode realizar otimizações (para tamanho e desempenho) no nível Java e no nível JavaScript. O código JavaScript padrão resultante pode ainda ser processado em seu pipeline de implantação. Por exemplo, uma prática comum que agora foi integrada à distribuição padrão do GWT envolve a otimização da saída JavaScript pelo transpilador usando o altamente especializado JavaScript-to-JavaScript Closure Compiler (outro presente dos deuses do Google).

A descrição mais detalhada do compilador GWT que conheço pode ser encontrada neste conjunto de slides e na palestra original de onde vem. Aqui, você pode encontrar detalhes sobre outros recursos interessantes do processo de compilação, como a capacidade do GWT de fazer divisão de código, gerando vários arquivos de script separados para serem carregados independentemente pelo navegador.

O JRE Emulado

O compilador Java-to-JavaScript seria pouco mais do que uma novidade se não fosse complementado por uma implementação do Java Runtime Environment (JRE), que fornece as bibliotecas centrais utilizadas por quase todos os aplicativos Java. Grosso modo, trabalhar em Java sem, por exemplo, métodos Collections ou String, seria frustrante e, claro, portar essas bibliotecas é um trabalho titânico. O GWT preenche esse buraco com o chamado JRE Emulado.

O JRE Emulado não é de forma alguma uma reimplementação completa do Java JRE, mas sim uma espécie de seleção de classes e métodos que podem ser úteis (e utilizáveis) do lado do cliente. As funcionalidades que estão no Java JRE, mas que você não encontrará dentro do Emulated JRE, se dividem em três categorias:

• Coisas que não podem ser portadas do lado do cliente. Por exemplo, java.lang.Thread ou java.io.File não podem ser implementados em um navegador com a mesma semântica de Java. A página do navegador é single-thread e não tem acesso direto ao sistema de arquivos.

• Coisas que poderiam ser implementadas, mas que “custariam muito” em termos de tamanho de código, desempenho ou dependências, e que a comunidade prefere não ter dentro do GWT. Incluído nesta categoria, por exemplo, está a reflexão Java ( java.lang.reflect ) que exigiria que o transpilador mantivesse informações de classe para cada tipo, e isso faria com que o tamanho do JavaScript compilado aumentasse.

• Coisas que ninguém tinha interesse e, portanto, não foram implementadas.

Se acontecer de o JRE Emulado não atender às suas necessidades (por exemplo, você precisa de alguma classe que não é fornecida), o GWT permite que você escreva sua própria implementação. Este poderoso mecanismo, disponível através da tag <super-source> , permite contornar problemas na hora de adaptar novas bibliotecas externas que utilizam partes do JRE não emuladas.

Pode ser muito complexo, ou mesmo impossível, fornecer uma implementação completa de algumas partes do JRE, portanto, para tarefas específicas, suas próprias implementações podem não seguir estritamente a semântica do JRE do Java, mesmo que funcionem no seu caso específico. De fato, se você está pensando em devolver suas classes ao projeto, lembre-se de que é de suma importância para o Emulated JRE que cada classe incluída siga a mesma semântica do Java JRE original. Isso garante que qualquer pessoa possa recompilar o código Java em JavaScript e confiar que obterá os resultados esperados. Sempre certifique-se de que seu código seja completamente testado antes de devolvê-lo à comunidade.

Camada de interoperabilidade

Para ser uma ferramenta eficaz para a produção de aplicativos da Web do mundo real, o GWT deve permitir que os desenvolvedores interajam facilmente com a plataforma subjacente. Ou seja, o navegador e o DOM.

Desde o início, o GWT foi desenvolvido para oferecer suporte a essa interação por meio da JavaScript Native Interface (JSNI), o que facilita muito o acesso às APIs no navegador. Por exemplo, usando recursos de sintaxe exclusivos do compilador GWT, você pode escrever o seguinte código Java:

 public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;

e você está livre para implementar o corpo do método em JavaScript. Você pode até mesmo envolver objetos JavaScript em um JavaScriptObject (JSO) e torná-lo acessível em seu código Java.

Um exemplo de onde essa camada entra em ação pode ser encontrado no contexto da composição da interface do usuário. O Java convencional sempre usou o kit de ferramentas padrão Widgets para construir elementos de interface do usuário, aproveitando a Java Native Interface para acessar os sistemas de janelas e entrada do sistema operacional subjacente. A camada de interoperabilidade do GWT faz a mesma coisa, para que os widgets tradicionais funcionem perfeitamente no navegador. A única diferença é que, neste caso, o sistema subjacente é o navegador e o DOM.

No entanto, os frameworks front-end nativos melhoraram rapidamente nos últimos anos e hoje oferecem vantagens significativas sobre os Widgets do GWT. À medida que essas estruturas cresceram em sofisticação, as tentativas de implementá-las no JSNI expuseram deficiências na arquitetura da camada de interoperabilidade. A partir da versão 2.7, o GWT introduziu o JsInterop, uma nova abordagem baseada em anotações Java, que permite integrar de forma rápida e fácil suas classes GWT com JavaScript. Não é mais necessário escrever métodos JSNI ou classes JSO. Em vez disso, você pode simplesmente usar anotações como @JSType ou @JSProperty , permitindo trabalhar com classes JavaScript nativas como se fossem Java.

A especificação completa do JsInterop ainda está em andamento, e as últimas atualizações só podem ser testadas compilando o código-fonte do repositório GWT. Mas já está claro que esta é a nova direção que permitirá ao GWT acompanhar as plataformas web em evolução.

Um projeto em andamento que aproveita o JsInterop é o recém-lançado gwt-polymer-elements, que disponibiliza todos os elementos de ferro e papel da Polymer para o GWT. O que é interessante nesta biblioteca é que os desenvolvedores não precisam gerar a API Java manualmente. O projeto usa gwt-api-generator para gerar a maioria das interfaces diretamente analisando a biblioteca Polymer e as anotações JSDoc. Isso torna mais fácil manter as ligações atualizadas.

Palavras finais

Com as melhorias no compilador, na camada de interoperabilidade e no desempenho e tamanho do código gerado nos últimos dois anos, fica claro que o GWT não é apenas “mais uma ferramenta de desenvolvimento web”, mas está a caminho de se tornar um importante kit de ferramentas de referência para o desenvolvimento de aplicativos web complexos e em larga escala, e pode até ser uma excelente opção para tornar aplicativos mais simples incríveis.

Uso o GWT diariamente em meu trabalho como desenvolvedor e consultor, mas principalmente adoro o GWT porque ele me permite ultrapassar os limites dos recursos do navegador e mostrar que os aplicativos da Web modernos podem ser tão poderosos quanto os aplicativos de desktop.

A comunidade do Projeto GWT é muito ativa, e novas bibliotecas, projetos e aplicativos baseados no GWT são constantemente propostos. Em Florença, o GWTcon2015, voltado para a comunidade, se reunirá no dia 11 de novembro. Se você estiver na região, espero que venha conhecer alguns dos principais desenvolvedores e conheça todas as oportunidades de fazer parte da evolução deste incrível kit de ferramentas.