Les nouveautés du Super Dev Mode

Venez prendre des nouvelles

Arnaud Tournier, le 27-01-2015

Les nouveautés du Super Dev Mode

Présenté par Brian Slesinsky, de Google, membre de l’équipe GWT.

Sommaire

  • Ce qui a changé depuis 2014,
  • Démo de débug avec SDBG,
  • Démo de débug dans Chrome Dev Tools,
  • Comment l’introspction des variables Java dans les Dev Toolds va s’améliorer.

Mort du Dev Mode

  • Mort du DevMode classique sur Firefox et Chrome,
  • Les Chrome DevTools fonctionnent maintenant bien avec 100 Mo de code JavaScript (un gros travail entre les équipes GWT et Chrome a été effectué),
  • Les fichiers SourceMap générés sont 70% plus petits,
  • Les équipes de Google sont passées au SuperDevMode et à Chrome (plus de 90% d’adoption),
  • Toutes ces améliorations sont présentes dans la version 2.7.

Les IDE lancent le SuperDevMode plus facilement

L’intégration du Super Dev Mode est établie dans Eclipse et IDEA 14 avec GWT 2.7.

Au même moment, les équipes GWT travaillaient sur les améliorations de la compilation incrémentale.

Toutes ces choses sont arrivées en même temps, provoquant un bond de productivité extraordinaire, toutes ces optimisations ayant un fort impact sur le cycle écriture-rafraichissement-debug-correction.

Démo de débug avec Eclipse

Avec la nouvelle version du plugin GPE, le lancement en SDB est très facile.

Brian nous montre la rapidité du compilateur incrémental : la première compilation prend quelques secondes, mais ensuite une petite modification dans le code se compile (presqu’) immédiatement.

Le plugin SDBG

Initié par James Nelson, maintenu par Ivan Markov. Provient du plugin Dart pour Eclipse ! Ce plugin permet de débugguer une application GWT dans Eclipse en pilotant un navigateur Chrome.

IE gère les source maps

C’était inatendu pour Brian. Mais pour Microsoft c’était essentiel pour intégrer correctement TypeScript.

Avec l’annonce de Microsoft de ne supporter qu’une seule version d’IE par version de Windows, et sachant que pour Windows 7 et 8.1, c’est IE 11, le débug en visualisant les sources Java dans IE est donc d’ores et déjà possible sur les plus utilisées des versions d’IE.

Débugguer avec GWT

Chrome Facile pour démarrer, fonctionne bien pour de grosses applications
IDEA 14.x + Chrome Sera l’objet d’une session séparée
Eclipse SDBG + Chrome Fonctionne bien, maintenance active

Débug dans Eclipse, avec la vue logique

Brian nous montre les progrès effectués autour du plugin SDBG. En ce moment, Ivan travaille activement pour mettre en place la déobfuscation des variables Javascript pour retrouver leur nom Java.

Brian pose un breakpoint sur lequel s’arrete Eclipse. On peut inspecter le contexte Javascript, et en plus les variables Java déobfusquées avec la vue structurelle (cette vue a à peine deux semaines d’age !).

Un seul problème : un breakpoint posé dans la méthode onModuleLoad() ne sera pas déclenché à cause d’une condition de concurrence. L’astuce consiste alors à insérer une ligne GWT.debugger() en début de onModuleLoad() et le breakpoint refonctionne.

Débug dans Chrome Dev Tools

Après avoir lancé l’application, dans les Dev Tools, aller dans l’onglet Sources et trouvez votre source Java. Vous pouvez y placer des breakpoints sur les lignes Java, Chrome place en réalité un breakpoint sur le code Javascript généré correspondant…

Ici, pas de déobfuscation des noms de variables, il va falloir reconnaitre à grosse maille nos variable Java déguisées en Javascript (en général c’est simplement un suffixe qui est rajouté au nom Java).

Mais là, même Brian s’embrouille à trouver la bonne variable Javascript, alors pour moi ma préférence reste à SDBG qui propose une bien meilleure intégration pour le développeur. Pour preuve, même après quelques minutes de recherche, Brian ne trouve pas sa variable et abandonne !

Améliorations à venir pour l’inspection des variables dans Chrome Dev Tools

Par exemple, quand il s’agit de visiter les valeurs d’une ArrayList - tâche plutot courante - il faut voyager à grand peine dans la foule des variables Javascript aux noms bizarres (voir paragraphe précédent).

Brian nous propose là une amélioration, développée conjointement avec l’équipe de Chrome Dev Tools. Une façon de pouvoir spécifier aux Dev Tools comment présenter un ensemble de variables Javascript de façon structurée.

Exemple pour la déobfuscation : les Widgets

Ici, on s’appuie sur cette nouvelle API pour inspecter plus naturellement les Widgets GWT.

    class Widget {
        Element element;
    }

    Widget
    |- element: HTMLDiveElement
        |- <class> com.google...Example2.Widget</class>

Formattage des objets, API

La fonctionalité s’appuie sur une API minimale permettant aux Dev Tools de demander à l’application comment formatter ses objets :

header(obj) retourne une structure, par exemple ["span", {}, "Widget(java)"] pour afficher le “sommaire” de l’entrée
body( obj) idem mais pour le corps intérieur de l’objet à inspecter
hasBody(obj) renvoie true ou false pour déclencher le formattage de l’intérieur de l’objet

Résultat de la démonstration : les Chrome Dev Tools affichent en effet une version lisible de ce que représente le Widget en question. Reste à voir si tout ceci va faire son chemin, car formatter l’ensemble des objets Java que rencontre quotidiennement un développeur Gwt représente un travail conséquent… Et tout cela pour se retrouver à débugguer son application dans le navigateur, avec des outils qui même performants sont loin de rivaliser avec un IDE comme Eclipse ou IDEA.

Types actuellement supportés

  • objets Java,
  • longs,
  • boxed numbers,
  • collections
  • maps
  • Java arrays
  • IndexedPanel
  • WidgetCollection

Travail à venir

  • Pour l’instant il faut Chrome Canary et GWT 2.7
  • Finaliser l’API de formattage
  • Faire fonctionner ceci sur le trunk de Gwt
  • Faire passer les tests de non-régression (attention aux changements dans le compilateur !!)
  • Supporter plus de débuggers
  • Formattage pour la pile d’appel

Questions ?

Pourquoi avoir une API pour définir ses formatteurs alors que le compilateur pourrait les générer automatiquement ?

Oui c’est bien le cas, il y aura un formatteur automatiquement généré qui prendra la main si aucun formatteur spécifique n’a été trouvé.

Comment activer le code formatteur ?

https://github.com/gwtproject/superdebug

Slides du talk : goo.gl/zFC9Wn


Arnaud Tournier, le 27-01-2015