.
I. Ce qui s'est passé depuis l'année dernière▲
Que peut-on retenir de la présentation de Ray Cromwell ? Tout d'abord un point sur ce qui s'est passé depuis la session à Google I/O 2012 :
- la mise à disposition du code source complet de GWT sur GitHub dans le but de mobiliser de façon plus importante la communauté des développeurs et de faciliter la participation au développement de GWT aux personnes motivées ;
- 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 provoqué de nombreuses rumeurs sur la mort de GWT, vous verrez par la suite qu'il n'en est rien - tout au contraire, car 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 RedHat dans le développement de GWT. On peut noter principalement leur engagement à héberger par l'intermédiaire de leur infrastructure Open Shift le service d'intégration continue du framework - ceux qui aiment voir de grosses entreprises présentes sur une technologie avant de l'utiliser se sentiront à l'aise ;
- un autre nouveau venu dans le comité de pilotage, et non des moindres : JetBrains. Une meilleure prise en charge de GWT dans IntelliJ est donc à anticiper. Apparemment Google et JetBrains s'entendent bien en ce moment (voir la sortie d'Android Studio, développé par Google sur la base d'IntelliJ !)
Depuis l'année dernière, peu de changements majeurs ont été apportés à GWT techniquement parlant, le point de focalisation étant la mise en place et le nouveau fonctionnement du comité de pilotage. Nous les développeurs n'avons pas été à plaindre, le cœur du framework étant très stable et mature, les projets clients peuvent toujours s'appuyer sur la version courante (GWT 2.5.1).
II. Le futur▲
Maintenant, couvrons le thème du futur de GWT, qui était le thème majeur de cette présentation. Voici les principes directeurs des futurs développements sur lesquels se sont accordés les membres du comité de pilotage :
- ouverture et simplicité (facilité à contribuer au projet pour des développeurs externes, les membres du comité étant autorisés à committer directement, et transparence dans la gestion du code source) ;
- rapidité (compilation et exécution) ;
- interopérabilité ;
- fiabilité (bug fix) ;
- intégration (avec d'autres outils) ;
- mobilité (phonegap et mgwt font partie du comité).
II-A. Ouverture et simplicité▲
En ce qui concerne l'ouverture il s'agit là de terminer le transfert vers la communauté open source principalement en rendant les meetings du comité de pilotage publics et réguliers. 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, ce qui est dû à 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 (à titre d'exemple, 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 cette mavenisation ? 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 les cas où seulement un sous-ensemble de modules sont utilisés.
II-B. Rapidité▲
Après, ou en parallèle de ce processus, un thème récurrent a toujours été la lenteur de compilation avec GWT. Celle-ci sera donc encore une fois un axe important d'amélioration. L'objectif est ici de doubler les performances de la compilation. Mais aussi 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 dans le navigateur directement en JavaScript avec les informations de déboguage qui permettent de voir le code source en Java dans le navigateur (mais pas le contenu des champs des objets :( - du moins pour l'instant, et c'est une des lacunes de SourceMap). Ceci permet d'éviter pour supporter le mode développement GWT la maintenance des plugins de développements (un pour Chrome, un pour Firefox et un pour Internet Explorer) et également d'éviter les allers-retours réseau entre le plugin du navigateur et la JVM donc d'améliorer les performances du mode de développement. En gros donc, à terme : plus de plugin à installer sur son navigateur pour le mode dev de GWT, mais tout se passera dans le navigateur ! Et avec une recompilation du code Java en JavaScript beaucoup plus rapide !
Ray a aussi cité la piste de la génération d'un code JavaScript plus 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 présente un gros potentiel pour l'amélioration des performances du code compilé. Le projet GWT émanant à son origine 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 !
II-C. Interopérabilité▲
En ce qui concerne l'Interopérabilité, outre le support complet des nouveaux Java 7 et 8 (Ray promet l'utilisation des lambdas à l'instant même où Eclipse publiera son ECJ/JDT pour Java 8), un effort va être 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 vers JavaScript, car GWT on le sait interopère déjà sans problème avec le monde JavaScript.
II-D. Fiabilité▲
En termes de Fiabilité, nous retiendrons principalement que les navigateurs Internet Explorer dans sa version 6 (au moins) devraient être retirés de la couche de compatibilité du projet. Une façon de dire aux décideurs IT : « si vous voulez profiter de la dernière version de GWT 3, soyez prêts à lâcher IE6 ! ». Sur un plan plus technique, cela permettra aux développeurs de GWT de s'affranchir d'une lourde dette technique qui met un frein notamment au 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 GWTUnit devrait aussi se voir amélioré.
II-E. Intégration▲
Toujours dans la ligne qui consiste à simplifier la structure du code de GWT, le projet devrait être découpé en plus petits 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).
II-F. Mobilité▲
Sur le plan de la Mobilité (et à ce moment, Daniel Kurka entre en action), il est é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 aussi sur l'optimisation de GWT pour le Web mobile : support des navigateurs mobiles, applications hors-ligne, widgets optimisés pour mobile, déploiement sur des plateformes de distribution d'applications mobiles (Apple Store par exemple !), etc. Tout ceci avec l'idée sous-jacente que la prise en compte des contraintes des terminaux mobiles est essentielle : 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, et puis malgré la couverture des réseaux mobiles modernes sur nos territoires (3G ou 4G) les débits 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.
À 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 au contraire de certaines bibliothèques qui exécutent les animations en JavaScript.
On peut noter que les bibliothèques mgwt et gwt-phonegap permettent d'ores et déjà de prendre en charge les terminaux mobiles en répliquant un graphique « natif » et en permettant l'accès aux fonctionnalités natives de ces plateformes.
III. Site Web et Roadmap▲
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).
En ce qui concerne les livraisons des nouvelles versions, nous allons avoir des nouvelles révisions mineures tous les six mois et des livraisons majeures tous les ans. Ray remercie chaleureusement +Thomas Broyer pour le nombre incroyable de bug fix qu'il a apporté cette dernière année.
IV. Conclusion et remerciements▲
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 terminer, outre mon envie de communiquer ma grande joie suite à cette présentation, je me contenterai de relayer le mot d'ordre : « Start contributing ! ».
V. Remerciements▲
Cet article a été publié avec l'aimable autorisation de la société PaloITPaloIT.
Nous tenons à remercier f-leb pour sa relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.
VI. Vidéo▲
Cliquez pour lire la vidéo
VII. Liens▲
- Lien de la vidéo de la session Google I/O
- Lien de l'article de Sami Jaber