Temps de compilation GWT

Une de faiblesse de GWT est le temps de compilation. En effet, les temps de compilations augmentent au fils des  développements et cela se révèle pénalisant à terme. L'équipe qui développe GWT l'a bien comprit et ne cesse d'optimiser le compilateur pour obtenir des temps de compilation plus courts. Entre la version 1.6.4 et la version 1.7.1 les temps de compilation ont été réduits de manière perceptible pour le développeur. Avec la version 2.0 et le nouveau "dev mode", le développeur gagne encore en réactivité.
Et les prochaines versions de GWT vont très certainement aller dans ce sens. 
En attendant, il est possible de "tuner" le paramétrage du compilateur pour obtenir de meilleurs résultats.
Tout d'abord, le paramétrage de la mémoire de la JVM est important (ex : -Xmx512m), car si le compilateur manque de mémoire il sera ralenti de manière significative.
D'autre part, les performances de votre CPU vont grandement influencer celles du compilateur. Si votre CPU est multi core alors il est possible d'utiliser le paramètre "-localWorkers n" avec n qui est le nombre de workers désirés.
Un paramétrage efficace consiste à avoir autant de workers que de cores. Idéalement, il faudrait avoir autant de cores que de permutations et que de workers.


Prenons un exemple concret. J'ai une application GWT d'une certaine taille (environ 36000 lignes de codes), qui occasionne 5 permutations. Je compile l'application sur une machine Intel Core 2 Duo. Voici les différents résultats que j'obtiens :

Paramètres		Temps de compilation
-Xmx256m	-localWorkers 1	109 secondes
-Xmx512m	-localWorkers 1	94 secondes
-Xmx512m	-localWorkers 2	81 secondes
-Xmx640m	-localWorkers 2	79 secondes

Avec ces résultats, on voit bien que ces deux paramètres influencent nettement le temps de compilation GWT. N'hésitez pas a les utiliser, car dans un projet chaque seconde compte.


En complément, vous pouvez gérer les permutation que le compilateur effectue. Pour cela vous pouvez spécifiez au niveau du module GWT (fichier *.gwt.xml) les navigateurs cibles, comme ceci :


<define-property name="user.agent" values="safari,opera"/>


NB : Avec GWT 2.0, un nouveau paramètre "-draftCompile" permet de demander au compilateur de ne pas procéder aux optimisations et donc de gagner du temps à la compilation.

Créer des fichiers *.deb

Ca y est vous venez de dénicher le logiciel qu'il vous manquait pour votre Ubuntu. Malheureusement pour vous, seulement les sources sont disponibles. Il va donc falloir compiler le logiciel et l'installer manuellement en ayant recours aux traditionnelles commandes :
./configure
make
sudo make install


Seulement avant que la compilation se déroule correctement, il va falloir résoudre manuellement les problèmes de dépendances. Donc une à une vous allez devoir installer les dépendances.
L'autre problème que vous allez rencontrer plus tard, c'est la désinstallation du logiciel, car il va falloir exécuter le processus inverse (manuellement).
Le but de cet article n'est pas d'expliquer les avantages d'utiliser les archives deb tellement ils semblent évidents, mais de montrer comment créer facile un fichier deb à partir d'un code source.
Pour cela il faut installer le package "checkinstall" avec la commande : 
sudo apt-get install checkinstall


Ensuite, il faut suivre le même processus d'installation à partir des sources (décrit ci-dessus) sauf qu'il faut remplacer la commande sudo make install par sudo checkinstall.
Un menu vous permettra de renseigner les informations du nouveau package, puis le fichier deb est généré.
Comme vous pouvez le constater la création d'un fichier deb est très simple. C'est pourquoi il ne faut pas hésiter à en créer car cela vous facilitera grandement la désinstallation du logiciel et sa future installation.
Si vous participer à un projet open source, la mise à disposition d'un package deb aidera votre projet a être connu.

Deep into GWT rpc request

By default, rpc calls doesn't haves timeout.
It is a problem when the network connection between the client and the server is interrupted, because the client rpc proxy waits indefinitely for a response that will never come... The management of the timeout depends on the version of GWT.


Management of the timeout with GWT version 1.x (tested with 1.6.4, 1.7.0 and 1.7.1) :


The first naive idea is to use the Timer class. This technique is not very elegant, because it monopolizes client side resources, and do not release http connection.
The problem is that RPC connection is a persistent http connection, and browser has a maximum number of http persistent connection per server.
So to solve this problem, we must be attentive to the interface of the asynchronous RPC service.


Typically service rpc methods are reflected in the asynchronous interface, with an additional parameter for callback and void return. But the proxy generator authorizes asynchronous  methods to return different kind of object : Void, Request and RequestBuilder.
In our case, we will use the object RequestBuilder, because we can defined a timeout with the methods "setTimeoutMillis". When an asynchronous  methods return a RequestBuilder object, for calling the remote method, we must explicitly call the "send" method of the RequestBuilder object. With this approach, when the timeout is reached, an RequestTimeoutException is throwed and the callback onFailure method is called.


Management of the timeout with GWT version 2.0 :


With GWT 2.0, it is possible to define its own RpcRequestBuilder class which define the timeout and will be used by the rpc proxy for asynchronous call of RPC service. Here's the code to implement :

Then, we must affect RequestBuilder to the rpc proxy, like this :

Faisons simple

Sous Ubuntu certaines manipulations sont très simples voir déconcertantes. 
Par exemple pour créer un fichier ISO à partir d'un cdrom ou dvd-rom la simple ligne de commande suivante suffit :
readom dev=/dev/scd0 f=/home/svuillet/test.iso

Autre exemple pour écrire sur cdrom ou dvdrom à partir d'un fichier ISO, la simple ligne de commande suivante suffit :

wodim -v -eject /home/svuillet/test.iso


Pas besoin d'installer quoi que ce soit, tout est nativement avec l'OS. 
Enjoy.

Javascript power

Si vous doutez encore de la puissance des applications écrites en Javascript, aller voir sur le site Chrome Experiments.
Vous vous apercevez que les limites des applications web "pure" (sans runtime), donc à base d'HTML5, de CSS3 et de Javascript, sont sans cesse repoussées. C'est assez bluffant et enthousiasmant pour l'avenir du web.
Vivement 2010 !

Un calendrier en ligne de commande

Sous Ubuntu, une ligne de commande peu connue mais très pratique, permet d'afficher le calendrier. Pour cela, rien de plus simple car il suffit de taper "cal" et le mois courant apparaît comme ceci :

Pour afficher l'année entière il faut utiliser l'argument "-y" et pour inverser l'affiche il faut utiliser le commande "ncal".

Cette commande est très simple mais tellement pratique une fois qu'on y a gouté...

GWT exception management

To handle exceptions in GWT, like in java we use blocks try / catch / finally.
Unfortunately, runtime exceptions can be forgotten if we do not use a try / catch / finally overall. 
GWT programs are highly asynchronous, and this characteristic force us to declare many blocks try / catch / finally. It is therefore not immune to a NullPointerException ...


Fortunately GWT provides a special handler to catch exceptions not caught : UncaughtExceptionHandler.
Once implemented the method "public void onUncaughtException (Throwable e)"
receive all the exceptions not catched. This solution is simple, effective and elegant, can be implemented afterwards without impacting the structure of the program.

WebGL prend vie

Le consortium Khronos, qui a pour objectif de standardiser la 3D dans le navigateur (en reposant sur OpenGL), et à l'origine du lancement de WebGL, un langage permettant de standardiser la 3D dans les navigateurs. Ce consortium regroupe Nvidia, Intel, ARM, AMD, Mozilla, Opera et Google.
Les derniers build de Firefox, webkit et maintenant chromium intègrent la prise en charge de WebGL (voir ici). Des démonstrations sont accessibles ici.
Voici une vidéo illustrant les capacités actuelles des browsers implémentant WebGL :





On peut aisément imaginer l'intérêt que cela devrait susciter auprès des éditeurs de jeux vidéos en ligne, mais aussi auprès d'éditeurs plus spécialisés (géo-localisation,  ...).

GWT ckeditor wrapper

Un nouveau projet consistant à wrapper ckeditor avec GWT est né.
Il est en version 0.1 donc tout jeune. Souhaitons lui longue vie.


La page officiel est ici.

Google day

Today is a special day. Google release GWT 2.0 with eclipse plugin.
This major version of GWT 2.0 will changed the way to develop web 2.0 applications.
This release coincides with the provision of 4 Chrome beta that supports the extension.
And finally, Google provides an extension called "Speed chart" that helps to profile web application.
Now GWT applications should be written very efficiently :-)

Take a look at this video (it sums up this crazy day) :

GWT memory management

La gestion de la mémoire dans une application GWT est particulière. Le garbage collector dépend directement du navigateur, c'est pourquoi il y a des différences de consommation mémoire d'un navigateur à un autre. Au delà de ce constat, il y a des pièges a éviter pour que le garbage collector puisse faire correctement son travail.

Tout d'abord, il faut savoir que la méthode "finalize" héritée de la classe Object, n'est pas appelée avant destruction d'un objet.
La seule méthode fiable pour libérer des ressources est la méthode "onDetach", car elle est appelé systématiquement lorsqu'un objet graphique (qui hérite de Widget) est détaché du DOM.

Le modèle évènementiel de GWT peut être une source de non libération de la mémoire si l'on ne s'assure pas que les composants sont désabonnés aux évènements au moment de leur détachement du DOM. Ceci est particulièrement vraiment si vous utilisez un bus d'évènements.
Deux autres sources de fuite mémoire sont l'utilisation de méthodes natives et la manipulation direct du DOM.
Enfin un point particulièrement sensible est l'abonnement aux évènements de type "Window", car les objets abonnés à ce type d'évènement resteront en mémoire tant que la page ne sera pas déchargée.

Voila un petit résumé des points à contrôler dans une application GWT pour éviter d'avoir des fuites mémoire.

Complément :

Une autre source de fuites mémoire et de ralentissements d'une application GWT est le non arrêt des timers. Il faut s'assurer que la méthode cancel de la classe Timer soit bien appelée.