Retour du Google I/O 2013 vers le futur de GWT

Nouveau logo GWTDu 15 au 17 mai s’est tenue la conférence annuelle Google I/O à San Francisco. Dédiée aux technologies Google, l’édition 2013 a rassemblé des milliers de développeurs passionnés du monde entier. Deux sessions abordaient GWT :

L’année dernière, j’avais écrit un premier article essayant de démontrer la pertinence d’utilisation de GWT en milieu industriel, malgré les doutes de sa Communauté sur sa pérennité. Ces deux sessions viennent le compléter.

Google IO

Ce qui a changé depuis l’année dernière

  • La mise à disposition du code source complet de GWT sur GitHub dans le but d’impliquer plus largement la Communauté des développeurs dans son développement;
  • La mise en place d’un nouveau système de revue de code basé sur Gerrit;
  • Le portage du site de GWT hors du domaine de Google, Google ayant remis le projet à la Communauté (ceci avait d’ailleurs provoqué de nombreuses rumeurs sur la mort de GWT mais vous verrez par la suite qu’il n’en est rien, bien au contraire : c’est pour mieux prendre en charge les besoins de la Communauté dans sa globalité et non les seuls besoins de Google en interne qu’a été initié ce mouvement);
  • L’implication de Red Hat dans le développement de GWT : on notera principalement leur engagement à héberger le service d’intégration continue du framework par l’intermédiaire de leur infrastructure Open Shift (ceux qui aiment voir de grandes entreprises présentes sur une technologie avant de l’utiliser peuvent se sentir rassurées !);
  • Un autre nouveau venu dans le comité de pilotage, et non des moindres : JetBrains. Une meilleur prise en charge de GWT dans IntelliJ est donc à prévoir. Apparemment, Google et JetBrains s’entendent bien en ce moment (cf. la sortie d’Android Studio, développé par Google sur la base d’IntelliJ ).

En conclusion : techniquement parlant, peu de changements majeurs ont été apportés à GWT, le point de focalisation étant la mise en place et le nouveau fonctionnement du comité de pilotage. Les développeurs ne sont pas à plaindre : le cœur du framework étant très stable et mature, les projets clients peuvent encore s’appuyer sur la version courante (GWT 2.5.1).

Le futur de GWT

Abordons maintenant le futur de GWT, thématique centrale des deux sessions présentées lors de la conférence Google I/O 2013. Voici les principes directeurs des futurs développements sur lesquels se sont accordés les membres du comité de pilotage :

  • Ouverture et simplicité

PuzzleEn ce qui concerne l’ouverture, il s’agit là de terminer le transfert vers la Communauté Open Source, principalement en rendant publics et réguliers les meetings du comité de pilotage. On facilitera aussi la participation de la communauté (avec la présence du code sur GitHub). Au fur et à mesure de son développement, le code de GWT est devenu un délicieux plat de spaghettis grâce à la richesse de cet outil, à l’activité frénétique que les développeurs lui ont consacré et à l’intégration de multiples bibliothèques patchées pour diverses raisons (ex. le serveur de développement intègre du code de Jetty, parfois d’Apache Commons, etc.). Ce phénomène peut devenir dangereux s’il n’est pas maîtrisé. Le comité de GWT en a tout-à-fait conscience et a démarré (par l’action de Thomas Broyer) la “mavenisation” du projet. Mais pourquoi ? L’intérêt de ce processus est de permettre la mise à plat des dépendances (parfois cycliques) entre les différentes parties du code de GWT ainsi que ses dépendances aux outils utilisés pour implémenter GWT (je citais Jetty tout à l’heure, mais il y en a d’autres). En fait, ceci permet de rationaliser l’ensemble du code source, et c’est très bien. Quiconque télécharge et chine dans le code de GWT se rendra compte très vite de la nécessité de ce travail. D’autre part, ce processus modularisera le code et permettra de réduire le temps de compilation dans le cas où seul un sous-ensemble de modules est utilisé.

  • Rapidité

RoadUne problématique récurrente a été constatée : la lenteur de compilation avec GWT. Elle incarne donc encore une fois un axe d’amélioration important. L’objectif est ici de doubler les performances de la compilation, mais également d’améliorer le SuperDevMode, une technique s’appuyant sur SourceMap qui permet de compiler à la volée en mode très rapide (draft) votre code pour l’injecter directement en Javascript dans le navigateur, accompagné des informations de debuggage permettant de voir le code source en Java dans le navigateur (mais pas le contenu du champs des objets 🙁 – du moins pour l’instant – et c’est une des lacunes de SourceMap). Ceci permet d’éviter la maintenance des plugins de développement (un pour Chrome, un pour FireFox et un pour Internet Explorer) mais également d’éviter les allers-retours réseau entre le plugin du navigateur et la JVM et donc d’améliorer les performances du mode de développement. En conclusion, à terme : plus de plugin à installer sur son navigateur pour le mode “dev” de GWT : tout se passera dans le navigateur ! Et avec une recompilation du code Java en Javascript beaucoup plus rapide !

Ray Cromwell a aussi évoqué la piste d’une génération de code Javascript en phase avec les machines virtuelles Javascript modernes. Le compilateur GWT ayant été développé avant même la sortie de V8 par exemple, il faudra prendre le temps de réaliser une investigation afin de peut-être revoir le code généré. Peut-on y voir aussi un signe de l’intégration de la technologie ASM.JS qui est en train de faire un gros carton en termes de performances sur Firefox, notamment avec Emscripten ? Nous verrons bien (attention ! ce propos n’engage que moi et des débats sur ce sujet existent). En tout cas, ce travail représente un gros potentiel pour l’amélioration des performances du code compilé. Le projet GWT émanant de Google, nous sommes de toute façon déjà très contents de l’efficacité du code JS généré aujourd’hui. Nous savons bien que pour Google, chaque milliseconde compte !

  • Interopérabilité

Outre le support complet des nouveaux Java 7 et 8 (Ray Cromwell promet l’utilisation des lambdas à l’instant même où Eclipse publiera son ECJ/JDT pour Java 8), un effort sera fait pour faciliter l’échange entre le monde Java-GWT et le monde JavaScript. Il s’agit de simplifier la syntaxe JSNI et de mettre en place des outils permettant l’intégration automatique de code Java <=> Javascript, car GWT, comme on le sait, interopère déjà sans problème avec le monde JavaScript.

  • Fiabilité

Nous retiendrons principalement le fait que le navigateur Internet Explorer (dans sa version 6 du moins) devrait être retiré de la couche de compatibilité du projet. Une façon de dire aux décideurs IT : “si vous souhaitez profiter de la dernière version de GWT 3, soyez prêts à lâcher IE6 !”. Cela permettra aux développeurs GWT de s’affranchir d’une lourde dette technique qui freine notamment le développement de widgets destinés aux plateformes mobiles. Outre ce point, Ray mentionne l’objectif de fixer les 100 bugs les plus importants du framework. Ne nous attardons pas dessus, mais GWT Unit devrait aussi être amélioré.

  • Intégration

Toujours dans l’optique de simplifier la structure du code en GWT, le projet devrait être découpé en plusieurs modules, avec l’adjonction de plusieurs points d’entrée destinés à faciliter l’intégration de GWT avec d’autres outils. Une des raisons à cette ambition est de faciliter l’intégration de GWT dans des produits industriels s’appuyant sur le cœur de GWT (Vaadin, JBoss ERRAI).

  • Mobilité

MobiliteSur ce sujet, Daniel Kurka entre en action ! Il semble évident qu’il n’est plus possible aujourd’hui de parler de développement Web en évinçant les terminaux mobiles. Et le comité de pilotage de GWT l’a bien compris, puisque l’accent va être mis sur l’optimisation de GWT pour le Web mobile : support des navigateurs mobiles, applications hors-ligne, widgets optimisés, déploiement sur des plateformes de distribution d’applications mobiles (Apple Store par exemple !), etc. Cependant :
– les CPU ne sont pas aussi rapides que ceux des machines desktop;
– les applications mobiles sont dépendantes de leur consommation en électricité (puisque les batteries de nos smartphones se déchargent assez rapidement);
– les débits de la couverture des réseaux mobiles modernes sur notre territoire (3G ou 4G) sont forts différents de ceux que l’on peut obtenir avec une connexion de type ADSL.
Il faudra prendre tout cela en compte, et c’est prévu. L’avantage de GWT sur ces points est que lors de la compilation d’un projet écrit pour GWT, toutes les ressources de l’application sont connues et peuvent donc être optimisées au maximum.

A titre d’exemple, prenons les animations graphiques : il est prévu que l’ensemble de celles-ci soient décrites en CSS par le compilateur GWT, ce qui permettra aux navigateurs mobiles de les faire exécuter sur le GPU, par le biais de leur moteur CSS à l’inverse de certaines bibliothèques qui exécutent les animations en Javascript. NB : les bibliothèques mgwt et gwt-phonegap permettent d’ores et déjà la prise en charge des terminaux mobiles en répliquant un graphique “natif”, ainsi que l’accès aux fonctionnalités natives de ces plateformes. Pour couronner le tout, on nous présente la migration et refonte du site GWT qui sort du domaine Google. Vous le trouverez à l’adresse suivante : http://www.gwtproject.org (au passage : ce site est une application GWT).

  • Livraison des nouvelles versions

Nous allons avoir des nouvelles révisions mineures tous les six mois et des livraisons majeures tous les ans. Ray Cromwell a d’ailleurs chaleureusement remercié +Thomas Broyer pour le nombre incroyable de bug fixes qu’il a apportés cette dernière année.

En conclusion…

En résumé, nos chers Ray Cromwell et son acolyte Daniel Kurka nous ont proposé (comme à leur  habitude) une magnifique session. Ceux qui suivaient déjà les activités du comité de pilotage ont pu confirmer leurs attentes. Et ceux qui doutaient de l’avenir de cette technologie se voient rassurés : l’avenir est brillant et les axes dans lesquels s’engagent les développements futurs de GWT sont en adéquation avec le sondage qu’avait effectué le comité auprès des utilisateurs de cette technologie. Pour conclure, outre mon envie de communiquer ma grande joie suite à cette présentation, je me contenterai de relayer le mot d’ordre : “Start contributing !”

Post-scriptum

Envie de plus de détails sur le sujet ? Je vous recommande vivement l’article de +Sami Jaber, LE spécialiste GWT en France.
Merci à +Thomas Broyer pour ses commentaires qui m’ont permis d’affiner ce post.

Retrouvez également cet article sur le blog d’Arnaud Tournier, Architecte Java GWT.

Share
Arnaud TOURNIER

848

Leave a Reply

Your email address will not be published. Required fields are marked *