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.
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.
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 :
