.
I. Qu'est-ce que le Super Dev Mode ?▲
Le Super Dev Mode est le remplaçant du Dev Mode permettant de lancer une application en cours de développement, et même de la déboguer depuis Eclipse.
Pour la petite histoire, c'est le troisième workflow de débogage pour GWT. Avant la version 2.0, GWT proposait un navigateur embarqué (et non standard, ce qui rendait l'expérience souvent douloureuse). GWT 2.0 apporta le « Dev Mode » (ou OOPHM, pour Out Of Process Hosted Mode) qui permit par un système de plug-in navigateur de déboguer une application directement dans les grands navigateurs du marché (IE, Chrome, Firefox). Avec le DevMode, l'application tourne directement dans la JVM (la compilation Java vers JavaScript n'ayant pas encore eu lieu), mais c'est le navigateur qui se charge de l'affichage. Pour déboguer, l'IDE est paramétré pour s'accrocher à la JVM, comme une application Java standard.
Alors, pourquoi un troisième mode de développement ?
À cette question, plusieurs réponses :
- l'architecture JVM + Plugin + Navigateur a le désavantage d'être très lente. En effet, à chaque fois que l'application interagit avec le navigateur (positionner un texte dans le DOM, ajouter un handler d'événement, réagir à ceux-ci), un échange a lieu entre la JVM et le navigateur par l'intermédiaire du plug-in. Comme une application Web passe la majeure partie de son temps à interagir avec le navigateur, il s'ensuit que la lenteur du Dev Mode devient rapidement problématique pour développer une application conséquente ;
- au bout de quelques rechargements, le Dev Mode consomme toute la mémoire allouée. Le runtime Java de GWT ne sait en effet pas quand le navigateur libère des ressources (éléments DOM, objets JavaScript). Le Dev Mode ne sait donc pas quand libérer les objets Java correspondants et ils s'accumulent indéfiniment. Ce problème est malheureusement insoluble ;
- le dernier argument, qui assène le coup de grâce au Dev Mode, vient de l'API native utilisée par le Dev Mode : la NPAPI. Cette dernière qui permet d'exécuter du code natif dans le navigateur a été créée dans les années 90 pour Netscape 2 (préhistoire !). Elle est aujourd'hui dépréciée par les fournisseurs de navigateurs (Google et Mozilla - Microsoft ne l'ayant jamais réellement supportée) pour plusieurs raisons, principalement de sécurité. Chrome et Firefox arrêtent son support dans l'année 2014. Il existe d'autres API pour interfacer le navigateur avec du code natif. En effet, mais selon Ray Cromwell, celles-ci ne permettent pas de faire des appels réentrants et ne sont donc pas de bonnes candidates pour supporter le Dev Mode.
II. Nouvelle architecture de débogage avec GWT▲
Le nouveau mode de développement s'appelle le Super Dev Mode. Il est supporté par le CodeServer et le standard Source Maps. L'idée est d'avoir un compilateur en mode super rapide et incrémental embarqué dans un serveur Web produisant non seulement le JavaScript à partir du code Java, mais aussi les informations Source Maps de façon à alimenter le navigateur avec les sources Java à l'origine de la compilation. Ainsi, on ne fera plus tourner l'application dans la JVM, mais celle-ci sera compilée à la volée en JavaScript et exécutée sous cette forme dans le navigateur. L'application en développement s'exécutera donc à sa vitesse (presque) nominale (pour la production, on ajoute en général toutes les optimisations possibles, alors qu'en développement on s'intéresse surtout à la vitesse de compilation).
Source Maps est un standard permettant aux nombreux outils de compilation ciblant du JavaScript de générer les informations nécessaires pour associer les lignes des fichiers source aux lignes des fichiers JavaScript générés par la compilation. Un navigateur compatible peut alors afficher le code source dans ses outils de développement directement, au lieu d'un code JavaScript incompréhensible (car souvent « minifié »).
Jusque là, tous les outils présentés sont compatibles avec tous les navigateurs modernes.
Ainsi, nous pouvons avec n'importe quel navigateur déboguer le code Java directement dans le navigateur.
III. SDBG - Le plug-in de débogage pour Eclipse▲
Ce plug-in est adapté du plug-in de développement des outils Dart (comme quoi, contrairement à certaines rumeurs, Dart ne tue pas GWT, mais le sauve !). Il permet de déboguer une application Source Maps et plus particulièrement GWT avec (presque) la même aisance que celle donnée par l'ancien Dev Mode.
Il permet de créer un launcher Eclipse qui va lancer Chrome. Grâce à son interface de débogage distant, le plug-in SDBG va « piloter » Chrome et donner à l'utilisateur des possibilités presque identiques au débogage Java. Le panneau d'inspection des variables d'Eclipse affiche seulement les noms JavaScript. Dans la plupart des cas, ceux-ci sont bien lisibles et vous pouvez faire la transcription mentalement.
IV. Installation▲
IV-A. Création du projet de démonstration de GWT en ligne de commande avec l'option maven▲
webAppCreator -out c:\tmp\TestGwtSdbg -maven fr.lteconsulting.testsdbgIV-B. Éditons ensuite le pom.xml▲
On utilise Java 7.
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>Ajoutez dans la zone des dépendances :
<dependency>
<groupid>com.google.gwt</groupid>
<artifactid>gwt-codeserver</artifactid>
<version>${gwtVersion}</version>
</dependency>et commentez la balise scope avec la valeur test de l'artefact gwt-dev :
<dependency>
<groupid>com.google.gwt</groupid>
<artifactid>gwt-dev</artifactid>
<version>${gwtVersion}</version>
<!-- <scope>test</scope> -->
</dependency>Changez la version de GWT pour le build de nuit : 2.7-SNAPSHOT. Tout cela ne fonctionne bien qu'avec la 2.7-SNAPSHOT. La 2.6.1 a des bogues source maps ! Et surtout elle n'a pas la dernière amélioration, l'option « -XcompilePerFile ».
<gwtversion>2.7-SNAPSHOT< /gwtversion>Pour obtenir ce snapshot, il faut ajouter le repository :
<repositories>
<repository>
<id>gwt-snapshots</id>
<name>Gwt Snapshots Repository</name>
<url>https://oss.sonatype.org/content/repositories/google-snapshots</url>
</repository>
</repositories>Dans la zone des plugins de build, changez la version du gwt-maven-plugin :
<plug-in>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.6.1</version>
</plug-in>Faites ensuite un mvn install pour télécharger le sdk. Cela peut prendre pas mal de temps…
IV-C. Importation du projet dans Eclipse▲
Importez le projet maven ainsi créé dans Eclipse.
IV-D. Activation du Super Dev Mode▲
Assurez-vous que le fichier du module GWT de l'application contient bien < add-linker name=« xsiframe » /> (plus tard ceci sera surement activé par défaut).
IV-E. Création du launcher CodeServer▲
C'est le compilateur GWT en mode ultrarapide intégré dans un mini serveur web. Il va recompiler l'application à la demande.
Créez le launcher de type Java Application dans Eclipse.
Spécifiez le projet courant et la classe main : com.google.gwt.dev.codeserver.CodeServer.
Dans les paramètres de ce launcher, indiquez le nom complet du module à servir ainsi que l'option pour activer la compilation par fichier : « fr.lteconsulting.testsdbg -XcompilePerFile ».
Dans la section Classpath, sélectionnez User Entries, cliquez sur le bouton « Advanced… », choisissez « Add folders », un Folder (advanced…->Folder) pointant vers les sources Java du projet (${projet}/src/main/java).
Lancez le launcher que l'on vient de créer, allez à la page « http://localhost:9876/ » et glissez les deux boutons « Dev Mode on » et « Dev Mode off » sur la barre des préférés du navigateur.
Arrêtez le launcher, votre navigateur est configuré.
IV-F. Installer le plug-in SDBG▲
Il ne reste maintenant plus qu'à installer le plug-in SDBG, celui qui va nous permettre de déboguer l'application GWT directement depuis Eclipse (alors que rappelons le, l'application tourne sous forme de JavaScript dans le navigateur).
Téléchargez l'archive la plus récente sur la page https://github.com/sdbg/sdbg/releases (celle-ci par exemple).
Dans Eclipse, ouvrez le menu Help, choisissez Install new software… puis Add… et enfin « Archive… ». Sélectionnez l'archive tout juste téléchargée et procédez à l'installation. Il faudra même redémarrer Eclipse.
IV-G. Création du launcher SDBG▲
Nous allons maintenant créer le launcher pour SDBG.
Ouvrez la dialogue « Run configurations » et créez un launcher du type « Launch Chrome ». Dans celui-ci, sélectionner « URL », renseignez l'url d'accès à l'application et le projet associé. Enregistrez ce launcher.
V. Lancer et déboguer une application▲
Voilà, nous avons fini la partie configuration, il ne nous reste plus qu'à lancer tout cela !
Avant de continuer, je vous conseille de lancer une compilation complète de votre application. Nous allons en effet souvent recharger la page et si vous n'avez jamais compilé, vous aurez la fenêtre « Your module may need to be recompiled », ce qui va être rapidement désagréable.
V-A. Lancement du serveur▲
Premièrement, lancez le serveur. Il peut s'agir de JBoss ou autre, ou bien simplement du Jetty embarqué dans Dev Mode classique (ne pas utiliser la partie ?gwt.codesvr=localhost:9997 de l'url).
V-B. Lancement du Super Dev Mode▲
Une fois l'application servie, il faut lancer le launcher Code Server. Celui-ci une fois lancé doit indiquer qu'il sert bien les requêtes à l'adresse http://localhost:9876.
Pour vérifier que tout fonctionne bien, avec Chrome ou Firefox, ouvrez la page de votre application, cliquez sur le bouton « Dev Mode on » que vous avez glissé dans votre barre des favoris auparavant, puis sur le bouton « Compile ». Le module doit se compiler et la page doit se recharger.
Normalement, avec les outils de développement de Chrome, vous devriez retrouver les sources Java.
Vous pouvez fermer cet onglet, le plug-in SDBG nous ouvrira le nôtre automatiquement.
V-C. Lancement du launcher SDBG▲
Maintenant, placez un breakpoint dans le code Java et lancez le launcher SDBG en mode débogage. Chrome s'ouvre (si ce n'est pas le cas, ajoutez -Dchrome.location=« chemin vers Chrome » dans votre eclipse.ini et redémarrez). Cliquez sur le bouton « Dev Mode on », puis sur le bouton « Compile » qui s'affiche. Normalement la page se recharge et le breakpoint est déclenché. La première fois de chaque session, un premier rechargement semble nécessaire…
Vous pouvez maintenant modifier le code Java, enregistrer et rappuyer sur « Dev Mode on » dans le navigateur. Vos changements sont recompilés et actualisés !
Voilà ! Vous avez découvert le nouveau workflow du nouveau mode de développement GWT.
VI. Avantages/Inconvénients▲
- Il y a moins de chance d'avoir une différence de fonctionnement entre la phase de développement et la production.
- Débogage sans plug-in navigateur, donc toujours à la page.
- Débogage des navigateurs mobiles.
VII. Conclusion▲
Le Super Dev Mode va encore évoluer dans les prochaines versions de GWT.
- L'équipe de développement de SDBG prévoit le remplacement de code à chaud (pas de F5 nécessaire pour bénéficier du nouveau code !).
- Pour l'instant, Source Maps ne supporte pas l'inspection des variables. Cela est en cours (de réflexion…).
- Bientôt RemoteDebug, une API de débogage unifiée pour tous les navigateurs et qui permettra d'utiliser SDBG avec tous les navigateurs.
VIII. Remerciements▲
Cet article a été rédigé par Arnaud Tournier. L'article original (Utiliser le nouveau Super Dev Mode avec le plug-in Eclipse SDBG) peut être vu sur le blog/site de Arnaud Tournier.
Nous tenons à remercier milkoseck pour sa relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.