I. Que s'est-il passé en 2015 ?▲
I-A. Changements techniques▲
À noter que la version bêta de GWT est disponible sur maven central, en utilisant la version 2.8.0-beta1.
![[ALT-PASTOUCHE]](./images/mavencentral.png)
Tout d'abord voici les améliorations techniques qui ont été développées. Celles-ci ont été présentées lors de la keynote de GWTCon 2015, conférence spécialement dédiée à GWT qui se déroulait à Firenze pour la deuxième année consécutive. Une sorte de GWT.Create organisé par la communauté des utilisateurs.
- GSS : le remplaçant de la partie CSS de ClientBundle (CssBundle) est maintenant stable (chez Google, toutes les applications GWT ont été migrées à GSS). L'ancienne implémentation CssBundle sera supprimée juste après la sortie de GWT 2.8. Par contre GSS ne sera finalement pas utilisé par défaut dans la version 2.8, de façon à ne pas bloquer la migration vers GWT 2.8. GSS produit de bien meilleures optimisations que CssBundle, on a donc tout intérêt à y migrer.
- De nouvelles fonctionnalités ont été ajoutées à GSS : entre autres la boucle for, la fonction concat(), l'annotation @gen-webkit-keyframes pour optimiser la génération des keyframes d'animation CSS.
- Temps de compilation : le SuperDevMode est six fois plus rapide que GWT 2.7. Par exemple, la compilation d'Inbox prenait 30 secondes avec GWT 2.7, ce temps a été réduit à 3 secondes. 100 % des applications GWT chez Google utilisent le SuperDevMode avec la compilation incrémentale. La compilation de production a elle aussi été améliorée avec l'introduction d'une nouvelle optimisation : pendant l'application des optimisations par le compilateur GWT, seul le code qui a changé est ré-analysé pour trouver de nouvelles optimisations possibles ; ceci a donné un gain de 20 % sur le temps de compilation pour les grosses applications de Google.
- JsInterop : les spécifications initiales ont été révisées et simplifiées pour une intégration encore plus fluide avec le JavaScript. Ces nouvelles specs ont été implémentées en totalité dans GWT 2.8, ne sont plus expérimentales et sont activées par défaut (à voir : la présentation approfondie de JsInterop à GWTCon 2015). Et maintenant que plusieurs personnes se mettent à l'utiliser, quelques fils de discussions pourront être intéressants pour le nouveau venu. Étant donné que JsInterop va être une des pierres angulaires de GWT, il est fortement conseillé de bien comprendre son fonctionnement.
![[ALT-PASTOUCHE]](./images/jsinterop.png)
- Support Java 8 : La syntaxe Java 8 est intégralement supportée (lambdas, références de méthodes, méthodes par défaut…). Au niveau des API de la JRE exploitant les nouveautés du Java 8, seules certaines seront implémentées comme @FunctionalInterface et Optional. Les streams seront par contre bien livrés avec la 2.8 ; au départ cette version devait paraître sans implémentation des streams, mais finalement ceux-ci entrent dans le périmètre de la 2.8.
- Intégration IDE (Eclipse) : Brandon Donelson est maintenant chargé de la maintenance de la partie GWT du plugin Google pour Eclipse.
- Utilisation de Source Maps : la génération des fichiers Source Maps est très importante pour garantir une expérience de débogage minimale, autant sur un navigateur qu'avec SDBG. L'équipe des Chrome Dev Tools a intégré de nombreuses améliorations et le débogage Java en est grandement amélioré.
- Web Components : rien de ce côté. De toute façon l'équipe attend la sortie officielle des web composants et leur support dans EcmaScript. Le problème est que la spécification n'avance pas, elle stagne même, et elle n'est pas très adaptée au modèle objet habituel en GWT.
- Performances : les opérations sur les HashMaps sont 2,8 fois plus rapides, les divisions Long sont cinq fois plus rapides. Les Double et Boolean ne sont plus boxés ce qui apporte un bon gain de performances.
- On peut noter également la possibilité d'accéder aux propriétés de compilation GWT de façon standard en Java en faisant : System.getProperty("foo.bar"). La propriété "foo.bar" pourra être définie dans un nœud define-property du module concerné.
I-B. Sorties de version▲
GWT 2.8 était annoncé pour mi-décembre lors de la conférence GWTCon à Firenze le 11 novembre 2015. Les délais n'ont pas été tenus, car la version 2.8-beta1 est toujours ouverte et reçoit des correctifs finaux, en nombre proportionnel à la quantité d'issues remontées par les bêta-testeurs… N'hésitez pas donc, à tester cette version, à vérifier la compatibilité avec votre code et surtout à remonter les anomalies.
I-C. Conférence GWTCon▲
![[ALT-PASTOUCHE]](./images/gwtcon.png)
Cette conférence s'est déroulée à Firenze en Italie le 11 novembre 2015. Une journée entièrement dédiée à GWT. Tous les membres du steering commitee étaient présents, avec Julien Dramaix pour représenter Google.
Voici les sessions que j'ai suivies, il y avait souvent deux conférences simultanément. Allez voir le site pour consulter les vidéos et les slides.
- Keynote (Julien Dramaix - Google) : annonces sur GWT 2.8 et 3
- GWT avec Polymer : Web Components en action ! (Manuolo Carrasco - Vaadin)
- Meilleures pratiques avec GWT (Christian Goudreau - Arc Bees)
- JsInterop avancé (Julien Dramaix - Google)
- Réalité augmentée avec WebGl (Francesca Tosi & Alberto Mancini - Jooik)
- Introduction à Errai 4 (Max - Redhat)
- GXT et les TouchEvents (David Chandler - Sencha)
- Maintenir de grosses applications : la console JBoss WildFly (Harald Pehl - Redhat)
- Écrire des applications sans gwt-user (Cristiano Constantini - Thalès)
- Une session sur le design pour les débutants (Manon Gruaz - Arc Bees)
- Introduction à la génération par annotation (JSR-269) : permet de remplacer les vieux générateurs GWT (Arnaud Tournier - LTE Consulting)
Voici une des vidéos de GWT Con, qui a sa propre chaîne sur YouTube :
Cliquez pour lire la vidéo
I-C-1. Singular▲
Beaucoup posent la question de ce qui se passe autour de ce framework… Singular est un projet qui avait été présenté et même annoncé au GWT.Create 2014, permettant de cross-compiler une base de code Java à la fois vers le navigateur et vers les plateformes mobiles. Tout ceci avec la génération de code natif sur Android et iPhone et un style de programmation à la Angular, sans les problèmes de performances, car les liaisons de données sont résolues à la compilation et n'utilisent pas de dirty-checking régulier pour fonctionner. Bref un projet assez alléchant finalement.
Une démonstration en avait été réalisée par Daniel Kurka et l'annonce avait été faite de la sortie prochaine d'une version bêta courant 2015. Mais il n'en a rien été ! Silence. C'est l'arlésienne…
Et la communauté a l'air d'attendre, en tout cas attendait, car les listes de diffusion liées au projet sont maintenant très inactives, quand ce n'est pas le message d'une personne qui demande des nouvelles.
Julien Dramaix a clarifié la situation lors de la conférence : Singular est bel et bien en stand-by, le temps d'assembler la première version de Jackal (le futur compilateur de GWT 3, voir plus bas) qui est la priorité numéro un de Google.
Il n'y a donc rien à attendre de ce côté-là pour le moment… Mais le projet n'est pas forcément mort pour autant. Bref, à ceux qui s'impatientaient de l'utiliser pour leur prochaine application : ce n'est pas pour tout de suite.
II. Feuille de route pour 2016 et plus▲
![[ALT-PASTOUCHE]](./images/roadmap.jpg)
GWT traîne derrière lui de nombreux fardeaux. Cet outil a en effet plus de dix ans et les décisions architecturales faites à l'époque de la conception ne sont désormais plus forcément idéales.
En résumé, GWT en fait trop : les permutations, la génération de code, les optimisations, le serveur de code SuperDevMode avec surveillance des fichiers source, des bibliothèques métier (Widgets, RPC, UiBinder…), etc.
GWT est apprécié pour le niveau de performance qu'il procure, et d'un autre côté il est détesté pour la lenteur de compilation et donc possède quelques désavantages par rapport à l'utilisation du JavaScript direct.
Google a donc décidé de (re) développer un compilateur Java vers JavaScript dont le nom est pour l'instant J2CL qui se prononce Jackal, « chacal » en français. Ce compilateur émettra du JavaScript ES6 comportant les annotations JsDoc Closure qui permettront au compilateur Closure Compiler de prendre en charge la partie optimisation.
Ce compilateur ciblera les fonctions modernes du JavaScript. Il devra être extrêmement rapide et complètement intégré avec le Closure Compiler.
Par contre, J2CL :
- ne sera pas un optimiseur ni un éditeur de liens (Closure prend ce rôle) ;
- ne fera pas d'injection de dépendance (utiliser Dagger2 par exemple) ;
- n'aura pas de mécanisme propre de génération de code (utiliser la JSR 269 standard en Java) ;
- ne sera pas un framework Web UI. En réalité J2CL ne sera même pas conçu autour du DOM.
La feuille de route n'est pas encore complètement définie, mais J2CL avance très vite. Il sera proposé en open source plus tard, au moment de la sortie de premiers prototypes d'abord confrontés aux besoins internes de Google.
À noter que, par exemple, Julien Dramaix travaille en ce moment sur l'intégration de ce compilateur avec les bibliothèques de définition « Definitely Typed » (de TypeScript), une sorte d'Elemental pour intégrer les milliers de bibliothèques JavaScript existantes. Ceci rendra triviale l'intégration avec des bibliothèques JavaScript existantes.
GWT quant à lui est maintenant un outil mature. La version 2.8 sera en LTR (Long Maintenance Release, version en maintenance longue). Il n'y aura plus d'évolution, mais seulement la correction des bogues.
Pour GWT 3, l'avenir n'est pas encore décidé. J2CL sera assurément un produit indépendant de GWT. Pour autant il pourrait tout à fait être intégré à GWT dans le futur. Google laisse le comité de pilotage en décider.
En résumé, tout est fait pour que GWT reste un produit de compétition pour les dix prochaines années !
III. Où va GWT ?▲
Voilà donc pour ce qui est des informations « officielles ». Laissons-nous aller à envisager et anticiper les tendances et la tournure que va prendre le projet dans les prochaines années.
Premièrement, on peut remarquer que programmer en Java est toujours aussi pertinent (voir par exemple le classement Tiobe de l'année dernière). Cela est d'autant plus vrai que pour des équipes historiquement Java (serveur en JEE par exemple), utiliser côté client le même langage de programmation peut même avoir un impact social, les développeurs client et serveur utilisant le même langage et ayant un vocabulaire et un environnement communs.
Produire des applications riches (nous ne parlons pas de « to-do list » ni d'applications à formulaire, mais d'applicatifs industriels) dans le navigateur a toujours un intérêt évident. Tant sur le plan du déploiement, de la compatibilité (le web fonctionne sur PC, Mac, Linux, Smartphones…), que sur le plan du périmètre technique offert par la plateforme (par exemple WebGL, accès au GPS, stockage local, webcam, etc.).
Malgré ces points restés pertinents, certains paradigmes techniques ont évolué depuis les dix dernières années :
- les navigateurs modernes sont maintenant compatibles, ainsi on n'a plus besoin d'avoir la couche d'homogénéisation qu'apportait GWT (de même que l'intérêt de JQuery n'est plus l'intégration des différents navigateurs, mais une présentation simplifiée de leur API). Le périmètre technique atteint sans utiliser de couche de compatibilité est maintenant bien assez large pour la plupart des besoins applicatifs. La plateforme web client est devenue une machine virtuelle de facto (API HTML5 très riches), et pourvu que l'on s'y prenne bien une application s'exécutera à la fois sur Mac, Windows, Linux, tablettes et smartphones ;
- l'écosystème de la plateforme web (JavaScript, CSS, HTML) est extrêmement riche et actif (bibliothèques, frameworks, langages). On a besoin d'une interopérabilité efficace et flexible. Le développeur d'une application doit pouvoir choisir parmi les innombrables bibliothèques disponibles sur la plateforme web.
Il est donc naturel que la place et le rôle de technologies comme GWT évoluent aussi.
Et ce mouvement est accompagné de la suppression annoncée pour GWT 3 d'une grosse partie des fondations des applications actuelles (Widgets, RPC, UiBinder…).
IV. Où allons-nous ?▲
![[ALT-PASTOUCHE]](./images/question.jpg)
Comment donc anticiper une migration progressive (cohérente avec l'évolution future de GWT, pas encore totalement définie, voire incertaine) lorsqu''on possède une base de code conséquente à maintenir ? Quels sont les défis ? Car bien sûr le but est rarement de stagner sur la version 2.8, mais bien de suivre l'évolution de l'outil, tant qu'il apporte de nouvelles fonctionnalités intéressantes. On peut donc voir GWT 2.8 comme une version transitoire, de préparation.
IV-A. Ce qui va disparaître▲
Examinons les pans de GWT voués à la disparition : générateurs, Widgets, GWT-RPC, UiBinder…
Tout d'abord, les générateurs peuvent être migrés vers la JSR-269. Cela représente un certain coût, et même parfois des compromis à faire, mais cela reste du domaine du réalisable. Quant aux autres parties, examinons-les une par une.
IV-A-1. RPC▲
Il est tout à fait envisageable de migrer vers une autre couche RPC. En effet, le périmètre fonctionnel de GWT-RPC étant assez restreint (il se résume globalement à la génération de stubs et proxy et se matérialise par des interfaces Java), le passage des générateurs à la JSR-269 devrait être possible, en dosant avec précaution le rapport entre coût de migration et complexité de la solution pour mimer exactement le comportement de GWT-RPC.
IV-A-2. Widgets▲
Sur ce point, l'intégration entre l'outil et le code applicatif est beaucoup plus fort, et l'approche objet qu'ils procurent est toujours utile. En effet, une application GWT contient souvent de nombreuses classes qui héritent ou utilisent Composite, ComplexPanel ou autre Widget. Toutes ces classes reposent sur le système de Widgets de GWT, qui va disparaître.
Deux choix vont certainement être possibles : migrer progressivement vers des outils de présentation comme Angular (avec JsInterop, Elemental et les futurs imports automatiques introduits par definitely typed, l'intégration de frameworks de présentation va être très aisée), ou bien continuer à développer sa couche de présentation directement en GWT, soit soi-même, soit en s'appuyant sur des bibliothèques qui, elles, auront migré vers JsInterop. D'autres qui s'appuient sur des bibliothèques comme GXT devront quant à eux attendre les décisions prises par ces outils.
Que proposent les Widgets ? Une gestion orientée objet de la hiérarchie du DOM et donc l'encapsulation pour le DOM, quelques sucres syntaxiques, ainsi qu'une gestion des événements particulière. En effet, créé à une époque où les navigateurs divergeaient énormément sur ce plan, GWT propose une surcouche unifiée à la gestion native des événements faite par les navigateurs. Cette surcouche est aujourd'hui devenue tout à fait obsolète avec la standardisation des navigateurs.
La plus-value des Widgets est donc l'encapsulation et l'approche objet (pour ceux qui aiment). Pouvoir donner à un code localisé dans une classe la responsabilité d'une partie de la hiérarchie du DOM est très utile. La valeur de cet atout disparaîtra peut-être avec la domination des Web Components, mais pour l'instant on peut attendre, car les Web Components n'apportent pas grand-chose en plus aux pratiques des développeurs GWT (encapsulation CSS, développement orienté objet sur le DOM…). La vision objet que procure un système de Widget rend la programmation très modulaire et facilite l'assemblage de parties logicielles hétérogènes.
D'un autre côté, un certain nombre de classes sont devenues fonctionnellement inutiles. Par exemple, la classe TextBox pour gérer un simple élément <input/>. Les comportements de cette balise sont suffisamment standards et souvent assez évolués en HTML5 pour s'appuyer sur la balise native.
De tout cela il reste que pour maintenir une application, il faudra faire interopérer (pour les migrer) des anciens Widgets avec des éléments DOM (et inversement) désormais vus de façon plus native à travers JsInterop, et il faudra que cela soit efficace, rapide et facile. Pourquoi ne pas donc imaginer l'écriture d'une bibliothèque de manipulation du DOM orientée objet, à x% compatible avec les Widgets, et basée sur JsInterop. Ceci fournirait à la fois une couche d'intégration et de migration, et la programmation-objet pour le DOM.
Sur le plan des Widgets et de la gestion du DOM donc, on voit bien que le champ des possibles s'agrandit. Chacun pourra choisir comment il compose son application. Et c'est cette question qui se posera lors de la création de nouveaux projets : quelle combinaison choisir ? Tout en Java ? Java + JS ? Java + TypeScript ? Java + Coffee + C# + … ? GWT-CSS ou PostCSS, Less, SaSS ? GWT + Angular, GWT + Meteor, GWT + React + Redux, GWT + React + Flux… ?
IV-A-3. UiBinder▲
En ce qui concerne UiBinder, le problème est double : il s'appuie sur les générateurs GWT et sur les Widgets. La partie générateur peut aussi être portée vers la JSR-269. Quant à la partie Widget, on retombe sur le problème évoqué un peu plus haut. La migration a donc un coût.
IV-B. Compétences Web▲
Le développeur Java GWT va devoir certainement augmenter ses compétences JavaScript/CSS/HTML car GWT en quelque sorte cachait ce monde. Et l'évolution de GWT va amener le Java à plus entrer en contact avec le JavaScript (et je pense que c'est tant mieux).
V. Conclusion▲
En somme de gros changements se préparent pour l'outil et les habitudes des développeurs. Aujourd'hui un projet GWT est assez standard (backend JEE, Widgets, RPC). Demain rien n'empêchera de faire du développement Java intégré avec un peu de Coffee (!), du TypeScript, D3.js et une UI en web composants développés avec Dart, le build étant géré par Gulp, le développement se faisant avec Atom, WebStorm ou Code. GWT qui est jusqu'à aujourd'hui central dans une application utilisant cette technologie (tout le code est écrit en Java pour GWT) va, je pense, s'intégrer aux autres technologies Web. Et le centre de gravité de telles applications devrait descendre vers les standards Web, ce qui permettra d'utiliser Java pour des composants précis (UI complexes, règles métier complexes, traitement structuré, réutilisation du code côté serveur, etc.) et JavaScript ou autre pour la facilité et la rapidité d'écriture. Ce ne sera donc plus GWT qui intègre le Web, mais le Web qui intègre GWT. Ceci est un changement marquant et très important dans l'évolution de l'outil. D'où ma recommandation aux développeurs GWT : familiarisez-vous avec la plateforme Web : JavaScript/HTML/CSS !
GWT peut aussi trouver sa place dans le développement mobile où l'enjeu se trouve dans la compilation vers les cibles natives comme les terminaux mobiles et peut être même l'IOT ensuite : Java comme langage, javac, GWT, Android SDK et J2ObjC comme compilateurs vers la plateforme Java, Web, Android et iOS. Inbox a en tout cas prouvé ce modèle.
Bref le monde évolue et GWT prend un tournant majeur pour garantir sa place. L'ouverture est au rendez-vous, avec deux mot-clés : intégration et performances.
![[ALT-PASTOUCHE]](./images/medley.png)
Informations recueillies par différentes sources : GWT Con 2015, sites, code…
VI. Remerciements▲
Cet article a été publié avec l'aimable autorisation de la société LTE Consulting.
Je tiens à remercier genthial pour sa relecture orthographique attentive de ce tutoriel et Mickael Baron pour la mise au gabarit.