GWT Create 2015

Résumé de la conférence annuelle

Arnaud Tournier, le 04-02-2015

GWT Create 2015

Les 27 et 28 janvier 2015 se déroulait à Munich la conférence GWT Create. Pour la deuxième fois, et pourtant avec déjà une odeur de rendez-vous annuel, les développeurs de GWT et ses utilisateurs ont pu se rencontrer, échanger et partager autour de ce fameux produit.

GWT est un outil permettant de créer des applications Web avec le langage Java. Il est développé par Google et son code est disponible en open source. Son pilotage est assuré par un comité composé de membres issus de Google, Red Hat, Arc Bees, Sencha, Vaadin et autres. C’est un outil mature – présent sur le marché depuis 2006 – qui a énormément évolué techniquement depuis sa création. Récemment cet outil a été mis sous le feu des projecteurs avec la sortie de Google Inbox qui l’utilise, mais aussi avec Google Spreadsheets, Google Adword, etc. Ces annonces arrivent à point nommé pour redorer l’image de cet outil qui subissait un flot insistant de rumeurs de mort, alors que ses développeurs s’appliquaient à implémenter la vision de son futur.

GWT n’est pas mort ! Au contraire, les nombreux sujets abordés pendant la conférence montrent le dynamisme du projet et de la communauté gravitant autour. Il y a de nouveaux outils (Singular)), de nombreuses améliorations apportées cette année (SuperDevMode et les futures fonctionnalités (support de Java 8, DeltaJS, …).

Avec un peu plus de recul, GWT a aussi des choix à faire. En effet le contexte dans lequel il baignait à sa création a changé : les navigateurs sont plus performants et plus homogènes, la sortie de HTML5 a amplifié le champ des possibles, les Web Components promettent de changer les pratiques, et l’écosystème Javascript est toujours plus grand. La programmation en Java et les nombreuses optimisations faites par le compilateur sont bien sûr toujours d’une valeur inestimable lors de la conception d’applications industrielles mais certaines problématiques ont tout simplement évolué. Les navigateurs étant plus homogènes, la couche de compatibilité fournie par GWT devient obsolète. D’autre part, l’avènement programmé des Web Components combiné avec le nombre croissant de bibliothèques Javascript disponibles rendront encore plus cruciale la facilité avec laquelle il sera possible de s’interfacer avec le langage Javascript.

Alors oui, la version 3.0 de GWT apportera des changements cassant la rétrocompatibilité. Ce sera le prix à payer pour suivre l’évolution des technologies Web. En attendant, la version 2.7 sortie cette année et la 2.8 à venir nous permettent d’entre-apercevoir la forme dans laquelle va se métamorphoser GWT.

M’étant rendu à cette conférence, je vais vous rapporter les éléments importants des sessions que j’ai pu suivre. Chaque session a aussi son article propre sur ce même blog. De toutes façons, vous pourrez retrouver sur le site de la conférence les supports de présentations ainsi que les vidéos des sessions.

Bonne lecture !

Les sessions

Voici la liste des sessions auquelles j’ai pu assister et le lien vers l’article correspondant (attention il s’agit parfois de simples notes mises en forme) :

  • Keynote du premier jour (lien),
  • Compilation incrémentale (lien),
  • Singular (lien),
  • Nouveautés du SuperDevMode (lien),
  • Google Inbox (lien),
  • Keynote du deuxième jour (lien),
  • GWT et Xtend (lien),
  • RestyGWT et Jersey (lien),
  • CellWidgets en liberté (lien),
  • Panel GWT (lien).

La keynote

La keynote a été présentée par Ray Cromwell. Cette année, GWT Create acceuille plus de 650 personnes, Etats-Unis et Europe confondus. 40 sessions ont été présentées.

Marketing : GWT change de logo et de page

Voilà c’est fait, le site de GWT change de visage, préférant un look plus moderne. Le logo aussi a été complètement revisité. Il est censé convoyer les notions de stabilité, d’expertise et de communauté. A vous de juger !

Présentation des nouveautés et du futur de GWT

Cette année a été prolifique pour GWT :

  • Le SuperDevMode et l’intégration avec SourceMaps a beaucoup avancé. Le débuggage dans Eclipse (ou IDEA) est maintenant possible grâce au plugin SDBG. Ceci redonne la main aux développeurs qui se sentaient perdus avec la perte du DevMode classique.
  • La compilation en mode développement est maintenant incrémentale, ce qui permet des temps de rafraichissmeent très réduits.
  • Toujours plus d’optimisations côté performances et taille des codes Javascript générés par le compilateur.
  • Support de GSS (un less/sass à la mode Google), qui remplacera à terme les CssResource.
  • La nouvelle couche d’intéropérabilité JsInterop a fait son apparition, permettant d’intégrer des bibliothèques Javascript encore plus facilement qu’auparavant avec JSNI.

Performances en terme de taille de JS généré

Les avancées prévues l’année dernière ont donc bien pu être implémentées, la vision était bonne. Quant aux futurs développements à venir pour la version 3.0, les voici :

  • Introduction de changements “cassant” au niveau des API !
  • Intégration du langage Java en version 8. Cela va permettre entre autres d’utiliser les lambdas et donc de réduire le code glue nécessaire pour écrire des callbacks.
  • JsInterop attaquera sa phase 2.
  • Débugguage : un outil développé en commun entre les équipes GWT et Chrome Dev Tools permettra d’afficher la structure logique des objets plutôt que les noms des variables internes générées par le compilateur (qui sont bien sûr souvent illisibles).
  • GWT va être découpé en plus petits modules.
  • Elemental 2.0 : cette outil permettant d’être à jour avec les dernières API navigateur est réécrite de fond en comble. Elemental sera même étendu pour aller chercher dans les bases de données de typage de Type Script (Microsoft), afin de pouvoir intégrer n’importe quelle bibliothèque Javascript en un coup de cuiller à pot, très prometteur !
  • Intégration de DeltaJS pour livrer les nouvelles versions des applications sous forme de patchs différentiels. Les Service Workers (une nouvelle API HTML 5) seront probablement mis à profit pour faire des mises à jour transparentes, et surtout pour délivrer un framework basique permettant d’exécuter nos applications sans connexion.
  • Des optimisations, encore et encore ! Améliorations des émulations du JRE, alignement avec les nouveaux paradigmes de ES6, etc…
  • Les développeurs seront incités à abandonner les Widgets, au profit d’une programmation plus près du DOM.

Le Super Dev Mode

En ce qui concerne le Super Dev Mode, que s’est-il passé depuis l’année dernière, puisque la mort du Dev Mode classique oblige le SDM à devenir de qualité industrielle ? Justement c’est ce qu’il s’est passé. Le SuperDevMode encore peu mature l’année dernière, mal intégré avec les Chrome Dev Tools (une application avec quelques dizaines de Mo de javascript faisait planter Chrome), avec beaucoup de bug sur Source Map, a beaucoup progressé.

A noter un travail intensif de collaboration entre les équipes GWT et Chrome Dev Tools a été mené, ce qui pour moi montre l’importance que Google donne à GWT. Les fichiers Source Maps générés sont environs 70% plus petits que l’année dernière. Et on peut noter aussi qu’en interne chez Google, toutes les équipes sont passées au SuperDevMode, ce qui prouve bien son industrialisation.

L’autre grosse nouveauté pour le SuperDevMode est la possibilité de déboguer son application directement dans l’IDE et non pas en passant par les Chrome Dev Tools, qui sont très bien au demeurant mais très limités si on compare à Eclipse ou IntelliJ. Ceci est donc une très bonne nouvelle. La seule limitation est que le débuggage n’est possible qu’avec un navigateur Chrome, FireFox et Internet Explorer n’étant pas encore pris en charge (ceux-ci supportant pourtant Source Maps sans problème). Les API de débogage des navigateurs ne sont en effet pas homogènes, ce qui obligent à dupliquer les connecteurs. Donc nous sommes plutôt dans un problème de temps avant d’y arriver, plutôt que sur des difficultés et inconnues techniques.

Tout ceci prend donc une très bonne voie, et pour ma part, je conseille à tous ceux qui ne l’ont pas encore fait de passer à GWT 2.7 + le plugin SDBG (pour Eclipse) ou IntelliJ (avec les fonctionnalités GWT) pour expérimenter le nouveau flow de développement, qui révolutionne l’ancien DevMode !

La compilation incrémentale

Détaillons un petit peu plus les avancées faites sur ce sujet. Une session de John Stalcup y a été entièrement consacrée. Tout d’abord, rappelons le principe de la compilation incrémental. Lors de la compilation classique, le temps que prend le compilateur à compiler votre application est fonction de la taille des sources utilisées dans votre application. En effet, plus votre application contiendra de source, plus la compilation sera longue. Et justement comme GWT est principalement destiné à écrire des grosses applications, le serpent se mord la queue et nous nous retrouvons souvent avec des compilations prenant plus de cinq minutes.

L’idée de la compilation incrémentale est de rendre le temps de compilation non pas fonction de la taille des sources de l’application, mais plutôt fonction de la taille des changements dans les sources depuis la dernière compilation. Et c’est dans ce sens qu’à évolué le compilateur GWT depuis l’année dernière. C’est un chemin qui avait été défini de longue date, mais évidemment il faut réviser entièrement l’architecture du compilateur et ce n’est pas une tâche aisée.

Un “proof of concept” avait été montré l’année dernière, mais il était largement immature, encore inefficace. Mais surtout cela a permis de défricher le terrain afin de soulever les inconnus liées à l’évolution du compilateur dans ce sens. Grâce aux efforts fournis par l’équipe GWT cette année, d’énormes progrès ont été réalisés. En effet, pour des applications réelles, le gain apporté par la compilation incrémentale vont de 5 à 15 par rapport à l’ancien Super Dev Mode. Tandis que les temps de chargement des applications sont eux aussi réduits (en général 3 à 4 fois plus rapide).

Pour l’histoire, l’équipe a dû changer plusieurs fois de stratégie pendant l’élaboration de la nouvelle architecture. Visant au départ à fractionner la compilation par bibliothèque ou carrément par fichier, cette stratégie s’est révélée trop compliquée pour gérer les dépendances au sein d’un projet. Même si compiler de façon indépendante les différentes parties d’une application semblait au départ une bonne idée, il s’est révélé qu’il était très pratique d’avoir un compilateur connaissant l’ensemble complet des dépendances du code d’une application, de façon justement à pouvoir calculer l’impact de changements dans une partie sur les autres. Le compilateur prend donc connaissance dans une première phase de travail de l’ensemble des dépendances de l’application pour ensuite passer à un mode “par classe” au fur et à mesure des compilations incrémentales.

Au final, la première compilation (lors du lancement du SuperDevMode) est encore un peu longue (quoique des améliorations déjà implémentées mais pas encore publiées sont d’ores et déjà capables de diviser par deux le temps de cette compilation initiale). Par contre, la recompilation après avoir apporter quelques changements au code est quasi-instantané dans la plupart des cas (je confirme, ndlr). Ceci va être une révolution pour les développeurs GWT habitués à un DevMode couteux en mémoire et très lent ! Si vous voulez déjà bénéficier d’une partie de ces améliorations, je vous conseille vivement de passer à GWT 2.7 !

Reste encore un problème de taille : les générateurs. Ceux-ci pénalisent en effet le temps de recompilation car le concept “incrémental” n’avait pas du tout été préparé au moment de l’écriture des interfaces entre les générateurs et le compilateur. Notamment, un générateur n’a pas la possibilité de spécifier ses dépendances au compilateur et donc un tas d’astuces ont été mises en place dans le compilateur pour essayer de “deviner” au mieux ces dépendances afin de ne refaire tourner un générateur que lorsque c’est nécessaire. On peut noter quand même l’apparition d’une nouvelle classe permettant à un générateur de spécifier plus de choses au compilateur. Mais qui a envie de réécrire tous ses générateurs ?

Quant à l’avenir de la compilation incrémentale, ce ne sont pas les idées qui manquent : déplacer le mécanisme des générateurs vers le build system plutôt que dans le compilateur afin de limiter les problèmes cités plus haut, revenir à la compilation par bibliothèque (ce qui améliorerait les temps de compilation d’applications réutilisant ces bibliothèques), une plus grande intégration avec Closure pour générer du code JS encore plus optimisé, … D’autres idées (plus risquées pour l’instant) aussi : avoir une sorte de class loader GWT pour charger du code dynamiquement dans la page, cache d’application automatique et mises à jours delta grâce aux Service Workers, généralisation du compilateur SDM à un serveur de compilation plus générique.

Le framework Singular

Ce nouveau framework présenté par Daniel Kurka pourra vous interresser car il est destiné à :

  • permettre la génération d’applications hybrides c’est-à-dire que pour un même code en entrée, il est possible d’obtenir :
    • une application Web classique,
    • une application native Android,
    • une application native iOS.
  • intégrer un mécanisme de data binding bi-directionnel à la façon d’Angular, mais sans ses désavantages (pour faire court Angular devient très lent à mesure que l’application grossit). En gros, l’idée de Singular est de faire un maximum de travail à la compilation de façon à produire un code très efficace à l’exécution (pas de timers pour le dirty-checking par exemple).

Edition d'un controlleur Singular dans Eclipse

Daniel a fait une démonstration de son produit (qui devrait sortir officiellement d’ici quelques semaines d’après lui). C’est très sympathique : le développeur écrit sa logique applicative indépendamment de la plateforme, puis écrit ses vues spécifiquement pour chaque plateforme, Singular gérant la liaison entre les deux parties.

Singular intègre une partie de PhoneGap pour délivrer une API unifiée pour toutes les plateformes prises en charge (Web, Android et iOS). Donc à terme j’imagine une bibliothèque de vues associée avec le look “material design”.

Le bilan est celui-ci : Singular permet de gagner en productivité car la logique applicative n’est codée qu’une seule fois. Les applications compilées avec Singular sont d’autre part très efficaces car en version native sur les plateformes mobiles.

Même si ce framework est tout jeune (il n’est même pas sorti d’ailleurs !), les concepts qu’il embraquent sont très interressants. A surveiller…

Google Inbox

Cette année, Google a fait grand bruit dans le monde GWT avec la sortie d’Inbox. Cette application a en effet servi de laboratoire pour établir un modèle de production d’applications hybrides. Par hybride, on entend que la même application Web peut être compilée dans une version native pour les plateformes mobiles.

En gros cette session raconte les problématiques qu’ont amenées le développement de cette application et les réponses qui ont été trouvées. Voici les points clés de cette architecture :

  • La partie logique applicative est codée en Java et est partagée par toutes les plateformes cibles.
  • L’application Web est codée avec des vues Web et générée avec GWT,
  • L’application Android est codée avec des vues Android et générée avec javac + dex,
  • L’application iOS est codée avec des vues iOS natives, la logique applicative est transpilée en Objective C grâce à J2ObjC, puis l’ensemble est compilé avec les outils iOS.

En conclusion, même si cette approche est certainement plus lourde qu’écrire simplement une application Web éventuellement wrappée pour les plateformes mobiles, l’approche permet de conserver du code commun entre les plateformes et surtout de conserver de bonnes performances sur les mobiles, tout en restant iso-fonctionnel. Cette lourdeur (écrire trois fois les vues) doit donc être justifiée. Pour Ray, une des plus grandes utilité de ce genre de pratiques est de pouvoir embarquer des bibliothèques complexes qui devraient être portées pour chaque plateforme sinon. Il cite quelques une de ces bibliothèques qui sont utilisées dans les produits Google et dont la réécriture (en Objective C par exemple) aurait été une énorme problématique :

  • Transformation opérationnelles (utilisées dans Google Spreadsheets),
  • Calcul de formules (Google Spreadsheets),
  • Mécanismes de synchronisation,
  • Cryptographie, Codecs, etc …

Pour autant le framework mis en place pour Spreadsheets et Inbox n’est pas vraiment industrialisé, donc pas de sortie grand public prévue pour le moment.

Le panel GWT

La dernière session de la conférence réunit les membres du comité de pilotage de GWT devant l’assemblée qui pose ses questions à volonté. Au menu des questions : trouver un argumentaire vendeur pour GWT, la qualité de la branche master du dépôt, le futur des Widgets, la tendance à programmer sur le DOM directement, les outils de build et l’intéraction entre la communauté et les développeurs.

Conclusion

Cette année encore GWT Create fût une conférence passionnante. Elle permet de consolider sa vision sur cette technologie et d’apréhender ses futurs axes de développement et donc de garder dans ses projets industriels une cohérence avec son futur. Mais surtout, c’est un lieu de rencontre où l’on peut échanger sur ses pratiques, et échanger tout court.

A l’année prochaine !


Arnaud Tournier, le 04-02-2015