↓ Arquivo ↓

Categoria → Sem categoria

Agilizando a compilação do GWT/Google Web Toolkit

Existem algumas coisas no mundo que demoram. Podemos citar entre elas a aprovação de qualquer coisa no congresso nacional, a redução de juros no Brasil e a entrega dos produtos enviados pela Deal Extreme. A compilação do GWT entra nesta categoria, mas ao contrário das 3 que citei, tem como melhorar “um pouco” seguindo algumas dicas.
O grande “problema” do compilador do GWT, é que ele tem um compromisso “sagrado” de tentar produzir um código Javascript melhor que o de um programador humano. Por isso, ele faz uma série de análises para que código não usado não seja convertido e não esteja presente no código final. Ele não deixa na versão compilada os métodos que você nunca usa e varíaveis nunca usadas. E também ele obfusca seu código. E isso leva tempo. Como diria a pensadora: “Isto não é feitiçaria, é tecnologia”. Por isso não existem milagres e essas dicas irão apenas ajudar a “diminuir a demora”.
Mas falando sobre a demora, existe outra coisa que pode deixar suas pausas para o café um pouco mais longas. É o fato de o GWT ter as “maravilhosas” permutações. Mas o que seriam as permutações Arnaldo? Isso pode? Claro que pode Galvão. As permutações são etapas em que o compilador do GWT compila diferentes versões do código para diferentes navegadores. Em vez de ter 1 código javascript com um monte de condições no meio tratando diferentes situações para diferentes navegadores, o compilador produz 1 código específico para cada navegador. Isso faz com que o código fique otimizado para o navegador do usuário, mas em contrapartida, faz com que a compilação fique mais demorada.
Irei falar sobre algumas opções para diminuir a demora. Você pode utilizar todas elas juntas, ou utilizar separadas. Fica a seu critério.

1. Evite utilizar Code Splitting

O Code Splitting é um recurso do GWT que posibilita que você quebre o código a faça com que ele seja carregado aos poucos.  O RunAsync(comando GWT.runAsync) serve para dizer onde se deve quebrar o código. Ele funciona bem, mas ele pode gerar um problema. São feitas uma série de análises adicionais para verificar os pontos de ‘quebra’ e separar os arquivos javascript a serem gerados. Dependendo do tamanho da aplicação e do número de pontos de quebra, a aplicação pode ficar ‘incompilável’ para muitas máquinas(por alto uso de memória e processamento). Então, analise a real necessidade de utilizar Code Splitting e se realmente aqueles KB’s a menos que o usuário irá carregar no início realmente farão diferença.

2. Go to hell IE6

Então daí que vem a segunda opção para diminuir a demora. Esta seria definir no GWT que você não quer compilar para alguns navegadores. Exemplo: Seu sistema só funcionará em IE8, Firefox 3 e Chrome. Não precisará funcionar em Opera, IE6, IE7 e versões antigas do Firefox. Então o que você faz é. Definir os navegadores que seu sistema terá suporte, e o resto que se f… fique sem compatibilidade. :) .
Para configurar os navegadores que você quer suporte, é só utilizar o seguinte comando no final de seu XML de configuração do módulo:

<set-property name=”user.agent” value=”ie6,ie8,gecko,gecko1_8,safari,opera” / >

Sendo as opções:

  • ie6 = Microsoft Internet Explorer 6 e 7;
  • ie8 = Microsoft Internet Explorer 8;
  • gecko = Mozilla Firefox 3.x e superiores;
  • gecko1_8 = Mozilla Firefox 1.5 e 2;
  • safari = Navegadores baseados em Webkit(Safari, Chrome, etc…);
  • opera = Opera.

3. LocalWorkers

Esta é a melhor técnica de todas as apresentadas na minha opinião. Consiste em você fazer com que sejam compiladas mais de 1 permutação por vez. Esta técnica só traz resultados reais para processadores de mais de 1 nucleo. Exemplo: Você tem um processador com 2 núcleos, então configuramos o GWT para compilar uma permutação por núcleo, sendo que ele sempre compilará 2 permutações simultaneamente.
Para configurar isso é fácil. È só passar um paramêtro para o compilador informando o número de localWorkers desejado. Para linha de comando é apenas “-localWorkers [numero]”. Em um script Ant é só utilizar o seguinte:

<java classname=”com.google.gwt.dev.Compiler” fork=”true” failonerror=”false”>
<arg value=”[modulo]” />
<arg value=”-localWorkers” />
<arg value=”[numero]” />
</java>

4. Verifique a configuração de localização.

Além de criar uma permutação para cada navegador, o GWT cria uma compilação por localização por navegador. Exemplo. Se eu tenho uma aplicação com suporte a todos os navegadores e com 2 opções de localização(ex: pt_BR e en_US), o GWT irá gerar 12 permutações, sendo que originalmente são 6. Se eu colocar mais uma opção de localização, o número de permutações sobe para 18. Então, se você vai utilizar apenas 1 opção, especifique para o GWT isso da seguinte forma, no arquivo XML de configuração do módulo:

<extend-property name=”locale” values=”pt_BR” />
<set-property name=’locale’ value=’pt_BR’/> <set-property-fallback name=’locale’ value=’pt_BR’/>

Utilizando o Google Web Toolkit(GWT) 2.0 Milestone 1 com o Google Plugin no Eclipse

Para utilizar o GWT 2.0 MS1 no Eclipse, é só seguir os seguintes passos:

  1. Baixe o GWT 2.0 no seguinte link: http://google-web-toolkit.googlecode.com/files/gwt-2.0.0-ms1.zip
  2. Descompacte o arquivo em um diretório de sua referência.
  3. Renomeie o arquivo gwt-dev.jar para gwt-dev-windows.jar
  4. Vá em Help, Check For Updates, e veja se tem alguma atualização do Google Plugin. Se tiver, instale-a.
  5. No Eclipse, já com o Eclipse Plugin instalado, vá em Project > Properties >  Google > Web Toolkit e clique em Configure SDK.
  6. Clique em Add e aponte para o diretório do GWT 2.0 e dê “Ok” em tudo
  7. Agora é só criar um projeto normalmente.

O GWT 2.0 não tem mais o “Dev Mode” do modo antigo, que era um browser próprio do GWT. Agora o “Dev Mode” apenas inicia um webserver(Jetty), e você deve instalar um plugin no browser de uma preferência para desempenhar a função do antigo browser embutido. O link para os plugins para os principais browsers:

Google Chrome

Instale a seguinte extensão: http://google-web-toolkit.googlecode.com/svn/trunk/plugins/npapi/prebuilt/gwtdmp.crx

Mozilla Firefox

Firefox 2(Mac PPC/x86, Linux x86/x86_64): http://google-web-toolkit.googlecode.com/svn/trunk/plugins/xpcom/prebuilt/gwt-dmp-ff2.xpi

Firefox 3(Win x86, Mac PPC/x86, Linux x86/x86_64): http://google-web-toolkit.googlecode.com/svn/trunk/plugins/xpcom/prebuilt/gwt-dmp-ff3.xpi

Firefox 3.5(Win x86, Mac PPC/x86, Linux x86/x86_64): http://google-web-toolkit.googlecode.com/svn/trunk/plugins/xpcom/prebuilt/gwt-dmp-ff35.xpi

Safari 3 e 4(apenas MacOS)

Baixe e instale a seguinte imagem: http://google-web-toolkit.googlecode.com/svn/trunk/plugins/webkit/prebuilt/oophm.dmg

Internet Explorer 6, 7 e 8(apenas 32 bits)

Baixe e instale o seguinte instalador: http://google-web-toolkit.googlecode.com/svn/trunk/plugins/ie/prebuilt/GwtDevModeIePluginInstaller.msi

Lançado o Google Web Toolkit (GWT) 2.0 Milestone 1

Hoje foi lançada a versão Milestone 1 do GWT 2.0. Essa versão vem sendo muito aguardada, pois é a que traz o maior número de novidades significativas desde a primeira versão do framework. A ultima grande mudança foi na versão 1.5, que trouxe a posssibilidade de codicar em Java 1.5. Anteriormente era apenas em Java 1.4, e com muitas limitações. Mas falando sobre a 2.0, as novidades que ela traz:

  • In-Browser Development Mode: Na minha opinião, a funcionalidade mais significativa. Você não fica mais preso ao browser padrão do GWT(no caso do Windows, o IE) para debugar. Você escolhe qual browser quer usar para ‘debug’. Algumas bibliotecas do GWT(GWT-EXT, GXT e SmartGwt por exemplo) tem problemas com compatibilidade com os browsers as vezes, ou erros que não são apresentados no Hosted Mode. Para aplicações grandes, que levam um certo tempo para compilar, para testar o sistema em browsers de verdade se torna um tanto quanto demorado. Agora não. Rode em modo ‘debug’ no browser que desejar, até em mais de 1 ao mesmo tempo, sem precisar compilar o projeto. Isso vai agilizar muito o processo de desenvolvimento.
  • Code Splitting: A aplicação não é mais monolítica. Nas versões anteriores do GWT, ele gerava um arquivo de Javascript único, onde estava toda a aplicação. Isso não é um problema para aplicações pequenas, mas para aplicações grandes em que o arquivo Javascript pode atingir facilmente uns 4MB, a coisa pode mudar bastante.
  • Declarative User Interface: Criação de interface de forma declarativa. Agora o GWT possui uma linguagem para criar telas. Em vez de criar as telas com Java, agora você cria com XML, assim como funciona no Adobe Flex por exemplo.
  • Bundling of resources (ClientBundle): Gerenciamento mais eficiente de recursos, como CSS, imagens, etc…
  • HtmlUnit e independencia de plataforma: Agora o GWT é independente de plataforma. Não vai mais existir 1 distribuição para cada S.O. O Browser e a Engine de testes baseada em SWT foram abandonadas, agora com uma implementação 100% Java.

Ainda não testei essa versão. Mas em breve irei fazer uma resenha mais a fundo sobre.

Download: http://google-web-toolkit.googlecode.com/files/gwt-2.0.0-ms1.zip

SmartGWT 1.0b1 lançado

A alguns dias atrás foi lançado(depois de algum tempo que foi anunciado o projeto) o SmartGWT. O SmartGWT é um wrapper dara SmartClient, que traz novos componentes, mais parecidos com desktop, para o GWT(Google Web Toolkit). Esse projeto é de autoria de Sanjiv Jivan, o mesmo que criou o GWT-EXT, que é um wrapper para o ExtJS.

Apesar de não ter utilizado ainda o SmartGWT, o que tenho que dizer é que é um projeto bem promissor e na sua primeira versão parece superar o GWT-EXT em muitos quesitos. O maior dele, acredito eu, seja os memory leak’s. A Isomorphic Software, empresa que desenvolve o SmartClient, diz que o mesmo é livre de memory leak’s. E pelos clientes deles, acredito que eles não iam falar apenas pelo “marketing”. Para quem utiliza GWT-EXT ou até mesmo ExtJS, sabe que o mesmo tem graves problemas com referências circulares em JS, “orphan nodes” e outras coisas. Para aplicações realmente grandes, isso se torna um grande problema, por a aplicação ficar acumulando a memória do navegador com coisas que deveriam ser eliminadas.

Para a versão 3(ou 2.3, não me lembro) do ExtJS, eles prometem acabar com esses problemas. Mas temos um problema aí. A licença. Até a versão 2.0.2 do ExtJS tinhamos uma licença como LGPL. A partir da versão 2.1, a licença foi alterada para GPLv3. E GPLv3 é(me corrijam se eu estiver errado) uma licença que te obriga a compartilhar o código, e “contamina” todos os projetos que utiliza código licenciado com a mesma. Ou seja, é uma licença que não serve para ser utilizada comercialmente, pois nesse caso o código necessita ser restrito, para grande parte das aplicações(não, o mundo não é tão ideal como o Stallman quer). E nesse caso, por caso disso, o GWT-EXT não pode acompanhar a evolução do ExtJS. O GWT-EXT ficou restrito a versão 2.0.2 do ExtJS, a última em LGPL. E no caso do ExtJS, ele tem LGPL misturado com uma licença própria, que impede de criar um fork do ExtJS. Então o melhor a ser feito foi tentar corrigir os problemas do ExtJS via GWT-EXT, para as aplicações que já existem não ficarem ser suporte e criar algo novo que possa ser evoluir para novos usuários. E aí que entra o SmartGWT.

O SmartClient era de código fechado até 2007. Eles da Isomorphic abriram o código e licenciaram como LGPL. E prometem mante-lo assim. E apoiam o projeto do SmartGWT. Ou seja, tudo caminha para que o SmartGWT seja uma ótima alternativa para o GWT-EXT. Tudo isso se os Lordes de Kobol concordarem. heheeh.

Links:

SmartGWT: http://code.google.com/p/smartgwt/

SmartClient: http://www.smartclient.com/

O blog voltou.

Olá. Se você visita regularmente o blog(coisa que garanto que nem eu faço), você deve ter reparado que ele estava fora do ar. O motivo foi que troquei de servidor e demorei 1 mês para tomar vergonha na cara e colocar o blog no ar novamente. Pois bem, agora voltou e não pretendo tirar do ar novamente tão cedo.

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!

…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe – quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Olá, mundo!

Bem-vindo ao WordPress. Esse é o seu primeiro post. Edite-o ou exclua-o, e aí comece a brincadeira!

Isso é o que dizia originalmente esta mensagem. Mas preferi editar ela. Migrei o blog. Agora em vez de utilizar o Blogger, ele utiliza o WordPress. O porquê da migraçãoÉ bom porque não tem slogan? È que agora que tomei vergonha na cara e contratei um serviço de hospedagem para colocar as coisas que desenvolvo e para outras coisas, resolvi instalar o WordPress. A migração foi muito fácil. A prova de idiotas diria. Mas vou tentar deixar o antigo e esse novo sincronizados por 1 mês, pois nem sei se esse serviço de hospedagem que contratei realmente é bom. hahaha. Se for bom ou ruim logo todos iremos saber. Mas é isso. Dessa vez quero ver se quando sobrar um tempo desenvolvo um template personalizado, mas por enquanto fique esse. Então é isso. Mais 1 Hello World para lista. Mas pelo menos desta vez foi uma segunda vez no mesmo blog. Nunca consegui postar mais de 2 mensagens no mesmo blog. Esse chegou a 17 com essa.

Hello World!

Mais um vez começando um blog.

Mas dessa vez vai, igual todas as outras milhões de vezes.