Tutoriel pour utiliser le Super Dev Mode GWT avec le plug-in Eclipse SDBG

Arnaud Tournier

Grâce à ce guide, vous pourrez installer le nouveau (futur) mode de développement et de débogage de GWT. Il est bien plus rapide que le classique Dev Mode et tout aussi puissant.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum. Commentez .

- Titre : Tutoriel pour utiliser le Super Dev Mode GWT avec le plug-in Eclipse SDBG

- Auteur : Arnaud Tournier

- Parution : 2 octobre 2014

- Mise à jour : 5 février 2020

- Licence : Copyright ® 2013 Arnaud Tournier. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Qu'est-ce que le Super Dev Mode ?

- II. Nouvelle architecture de débogage avec GWT

- III. SDBG - Le plug-in de débogage pour Eclipse

- IV. Installation

- IV-A. Création du projet de démonstration de GWT en ligne de commande avec l'option maven

- IV-B. Éditons ensuite le pom.xml

- IV-C. Importation du projet dans Eclipse

- IV-D. Activation du Super Dev Mode

- IV-E. Création du launcher CodeServer

- IV-F. Installer le plug-in SDBG

- IV-G. Création du launcher SDBG

- V. Lancer et déboguer une application

- V-A. Lancement du serveur

- V-B. Lancement du Super Dev Mode

- V-C. Lancement du launcher SDBG

- VI. Avantages/Inconvénients

- VII. Conclusion

- VIII. Remerciements

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

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