La boîte à outils GWT : créez de puissants frontaux JavaScript à l'aide de Java

Le GWT Web Toolkit, anciennement connu sous le nom de Google Web Toolkit, est un ensemble d'outils de développement permettant de créer et d'optimiser des applications complexes basées sur un navigateur à l'aide du langage de programmation Java.

Ce qui fait que GWT n'est pas "encore un autre outil Java pour écrire des applications Web", c'est le fait que le cœur de la boîte à outils est un compilateur qui convertit Java en JavaScript (ainsi que HTML et CSS), permettant aux développeurs d'écrire des applications Web frontales. tout en tirant parti de toutes les forces de Java.

Il est même facile d'utiliser un mélange de Java et de JavaScript, car GWT inclut une architecture d'interopérabilité robuste pour l'interface avec la plate-forme Web. Tout comme l'interface native Java (JNI) permet à la machine virtuelle Java (JVM) d'appeler des routines spécifiques à la plate-forme (par exemple, pour accéder à des fonctionnalités matérielles spécifiques ou utiliser des bibliothèques externes d'autres langages), GWT nous permet d'écrire la plupart d'un application en Java, puis, si nécessaire, d'utiliser une API Web spécifique ou, de tirer parti des bibliothèques JavaScript existantes, de "devenir natif" et de sauter dans JavaScript.

GWT est né en tant que produit Google mais est passé à l'open source fin 2011 et est aujourd'hui publié sous licence Apache (version 2) sous le nom de GWT Open Source Project . Il est géré par un comité de pilotage composé de représentants de plusieurs sociétés, dont Google, RedHat, ArcBees, Vaadin et Sencha, ainsi que de développeurs indépendants de la communauté.

GWT dans le passé et dans le futur

Le Google Web Toolkit a été lancé pour la première fois en 2006. Il a été créé comme un outil pour aider les ingénieurs de Google à développer leurs applications complexes basées sur un navigateur, telles qu'AdWords, Google Wallet et Google Flights, et, plus récemment, il est utilisé au cœur de Applications Google Sheets et Inbox.

En 2006, les navigateurs (et les interpréteurs JavaScript) étaient loin d'être standardisés. Le code frontal était lent, bogué et difficile à utiliser de manière fiable. Il y avait un manque presque total de bibliothèques et de frameworks de haute qualité pour le développement Web. Par exemple, jQuery n'existait même pas avant cette année. Ainsi, pour pouvoir développer des applications Web à grande échelle, les ingénieurs de Google ont décidé de tirer parti des outils et des compétences existants. Java était le langage le mieux adapté à leurs besoins, étant bien connu et parfaitement intégré dans les IDE, comme Eclipse, et c'est ainsi que le Google Web Toolkit a commencé sa vie.

L'objectif était plus ou moins de masquer les différences entre les navigateurs et d'encapsuler les astuces nécessaires pour écrire du JavaScript efficace dans un compilateur Java, laissant les développeurs libres de la tyrannie des détails techniques des navigateurs.

Bien sûr, au cours de la dernière décennie, le Web a changé ; les navigateurs sont devenus plus rapides et ont convergé sur les normes d'implémentation, et de nombreux frameworks et bibliothèques frontaux impressionnants ont été développés, notamment jQuery, Angular, Polymer et React. Donc, la première question que vous pourriez naturellement vous poser est : « GWT est-il toujours utile ?

En un mot : Oui .

Dans le contexte du développement web moderne, le ciblage des navigateurs est incontournable et JavaScript est devenu la lingua franca des applications front-end. Mais bien sûr, différents outils et langages sont mieux adaptés à différentes tâches. GWT, ainsi qu'une poignée de projets similaires, visent à cibler les navigateurs sans limiter les développeurs à l'utilisation de JavaScript.

Le développement et l'utilisation d'outils « compile-to-the-web » comme GWT seront, dans un proche avenir, facilités par le groupe dit WebAssembly du World Wide Web Consortium. Il existe non seulement un vaste espace pour les outils qui compilent en JavaScript, mais cette approche peut répondre à un réel besoin dans des contextes allant du déchargement d'une partie du calcul aux navigateurs, en passant par la réutilisation du code et des bibliothèques existants, le partage de code entre le back-end et le front-end. , en utilisant les compétences et les flux de travail existants et en tirant parti des fonctionnalités de différentes langues (par exemple, le typage statique dans le cas de GWT).

Le projet GWT devrait bientôt sortir la version 2.8, et la version 3.0 est en cours de développement, avec de grandes améliorations en préparation :

• interopérabilité réinventée avec JavaScript
• compilateur amélioré (presque totalement réécrit)
• support Java de pointe (par exemple lambdas)

En fait, la plupart des fonctionnalités de GWT 3.0 sont déjà disponibles sur le dépôt public Git. Il suffit de vérifier le tronc, ici et de compiler GWT en suivant la documentation ici.

La communauté GWT

Depuis que GWT est devenu open source en 2011, la communauté a assumé un rôle central dans l'évolution du projet.

Tout le développement se déroule sur le référentiel Git hébergé sur gwt.googlesource.com, et toutes les révisions de code sont effectuées sur gwt-review.googlesource.com. Sur ces pages, toute personne intéressée par le développement de la boîte à outils peut contribuer et voir sur quoi travaille la communauté. Au cours des dernières années, le pourcentage de nouveaux correctifs provenant de non-googleurs est passé d'environ 5 % en 2012 à environ 25 % l'année dernière, ce qui confirme l'implication croissante.

Cette année, la communauté s'est réunie pour quelques grandes réunions aux États-Unis et en Europe. GWT.create, organisé par Vaadin, s'est tenu à Munich, en Allemagne et à Mountain View, en Californie, en janvier, et a compté plus de 600 participants de dizaines de pays. Le 11 novembre, à Florence, en Italie, nous tiendrons la deuxième édition de GWTcon, une conférence communautaire GWT que j'aide à organiser.

À quoi GWT est-il adapté ?

Une enquête annuelle sur la boîte à outils GWT, publiée par Vaadin, traite de l'évolution du développement de GWT, de ce que les développeurs pensent de la boîte à outils, des bons, des mauvais, etc. Cette enquête nous permet également de comprendre à quoi sert la boîte à outils, comment la communauté des utilisateurs évolue et les attentes des développeurs quant à l'avenir de la boîte à outils.

Le rapport sur l'avenir de GWT pour 2015 peut être trouvé ici, et il montre clairement que GWT est très populaire pour la création d'applications Web à grande échelle. Par exemple, à la page 14, il est écrit : « La plupart des applications sont des applications métier qui sont lourdes en données et avec lesquelles on travaille plusieurs heures par jour.

Comme prévu, il est facile de conclure que l'environnement naturel de GWT est le domaine des applications Web à grande échelle, où la maintenabilité du code est importante, et où les grandes équipes bénéficient de la structure du langage Java.

D'un autre côté, en regardant les benchmarks du code généré par GWT (par exemple, dans le keynote de la conférence GWT.create de l'année dernière, aux pages 7, 8 et 11), il est facile de voir qu'en termes de performances et taille du code, le JavaScript compilé est incroyablement génial. S'il est utilisé correctement, les performances obtenues sont comparables au meilleur JavaScript écrit à la main. Par conséquent, il est en fait possible d'utiliser GWT pour porter les bibliothèques Java sur le Web.

Cela éclaire un autre scénario idéal pour GWT. L'écosystème Java regorge de bibliothèques de haute qualité qui n'ont pas d'équivalent prêt à l'emploi en JavaScript. Le compilateur GWT peut être utilisé pour adapter ces bibliothèques pour le Web. En d'autres termes, GWT nous permet de mélanger des bibliothèques disponibles à la fois en Java et en JavaScript, et de les exécuter dans le navigateur.

Cette approche peut être vue dans le développement de PicShare, où nous montrons comment plusieurs bibliothèques Java qui ne sont généralement pas considérées pour le Web (NyARToolkit par exemple) peuvent être portées sur le navigateur à l'aide de GWT, et combinées avec des API Web, notamment WebRTC et WebGL, pour obtenir un outil de réalité augmentée entièrement basé sur le Web. J'étais fier de présenter PicShare à la conférence GWT.create 2015 en janvier dernier.

Sous le capot : transformer Java en JavaScript

Le GWT Toolkit est un ensemble d'outils modérément complexe, mais n'importe qui peut commencer à l'utiliser en un tournemain, grâce à une intégration étonnamment facile à utiliser avec Eclipse.

Créer une application simple avec GWT est relativement facile pour toute personne ayant une expérience dans les projets de développement Java. Mais pour comprendre ce qui "se passe réellement", il vaut la peine d'analyser les principaux composants de la boîte à outils :

• Transpilateur Java vers JavaScript
• Environnement d'exécution Java émulé
• Couche d'interopérabilité

Compilateur d'optimisation de GWT

Une description détaillée du fonctionnement du compilateur devient assez tôt très technique, et nous n'avons pas besoin de creuser aussi profondément, mais certains des concepts généraux valent la peine d'être examinés.

La première chose à comprendre est que GWT compile Java en JavaScript par traduction au niveau du code source. C'est-à-dire que la source Java est traduite ( transpilé est le terme technique) en JavaScript. Cela contraste avec une sorte de machine virtuelle Java écrite en JavaScript, qui exécute le bytecode Java. (C'est en fait possible, et c'est l'approche utilisée par Doppio, mais ce n'est pas ainsi que GWT fonctionne.)

Au lieu de cela, le code Java est décomposé en un arbre de syntaxe abstraite (AST) représentant les éléments syntaxiques du code. Il est ensuite mappé sur un AST Javascript équivalent (et optimisé), qui est finalement reconverti en code JavaScript réel.

Peser le pour et le contre de la transpilation est loin d'être l'objet de cet article, mais permettez-moi d'observer qu'avec cette méthode, GWT peut directement tirer parti des services de récupération de place de l'interpréteur JavaScript, ainsi que de toute autre fonctionnalité native du navigateur.

Il y a des parties délicates, bien sûr. Par exemple, JavaScript n'a qu'un seul type numérique, qui ne peut pas contenir le type entier long 64 bits de Java, de sorte que les types long nécessitent un traitement spécial par le compilateur. De plus, le typage statique Java n'a pas de signification directe en JavaScript, il faut donc faire particulièrement attention à garder, par exemple, les opérations de transtypage équivalentes après la transpilation.

D'un autre côté, un avantage facilement appréciable de la transpilation est que GWT peut effectuer des optimisations (tant pour la taille que pour les performances) au niveau Java et au niveau JavaScript. Le code JavaScript standard résultant peut même être traité ultérieurement dans votre pipeline de déploiement. Par exemple, une pratique courante qui a maintenant été intégrée dans la distribution GWT standard consiste à optimiser la sortie JavaScript par le transpileur à l'aide du compilateur de fermeture JavaScript-to-JavaScript hautement spécialisé (un autre cadeau des dieux de Google).

La description la plus détaillée du compilateur GWT que je connaisse se trouve dans ce jeu de diapositives, et dans la présentation originale dont il est issu. Ici, vous pouvez trouver des détails sur d'autres fonctionnalités intéressantes du processus de compilation, telles que la capacité de GWT à diviser le code, en générant plusieurs fichiers de script distincts à charger indépendamment par le navigateur.

Le JRE émulé

Le compilateur Java vers JavaScript ne serait guère plus qu'une nouveauté s'il n'était pas complété par une implémentation de l'environnement d'exécution Java (JRE), qui fournit les bibliothèques de base sur lesquelles reposent presque toutes les applications Java. En gros, travailler en Java sans, par exemple, les méthodes Collections ou String, serait frustrant, et bien sûr, porter ces bibliothèques est un travail titanesque. GWT comble ce vide avec ce que l'on appelle le JRE émulé.

Le JRE émulé n'est en aucun cas une réimplémentation complète du Java JRE, mais plutôt une sorte de sélection de classes et de méthodes qui peuvent être utiles (et utilisables) côté client. Les fonctionnalités qui sont dans le JRE Java mais que vous ne trouverez pas dans le JRE émulé se répartissent en trois catégories :

• Choses qui ne peuvent pas être portées côté client. Par exemple, java.lang.Thread ou java.io.File ne peuvent pas être implémentés dans un navigateur avec la même sémantique de Java. La page du navigateur est monothread et n'a pas d'accès direct au système de fichiers.

• Des choses qui pourraient être implémentées mais qui « coûteraient trop cher » en termes de taille de code, de performances ou de dépendances, et que la communauté préfère donc ne pas avoir au sein de GWT. Dans cette catégorie, par exemple, se trouve la réflexion Java ( java.lang.reflect ) qui obligerait le transpileur à conserver les informations de classe pour chaque type, ce qui entraînerait un gonflement de la taille du JavaScript compilé.

• Des choses qui n'intéressaient personne et qui n'ont donc pas été mises en œuvre.

S'il arrive que le JRE émulé ne corresponde pas à vos besoins (par exemple, vous avez besoin d'une classe qui n'est pas fournie), GWT vous permet d'écrire votre propre implémentation. Ce mécanisme puissant, disponible via la balise <super-source> , permet de contourner les problèmes lors de l'adaptation de nouvelles bibliothèques externes qui utilisent des parties du JRE non émulées.

Il peut être trop complexe, voire impossible, de fournir une implémentation complète de certaines parties du JRE, donc pour des tâches spécifiques, vos propres implémentations peuvent ne pas suivre strictement la sémantique du JRE de Java, même si elles fonctionnent dans votre cas spécifique. En effet, si vous envisagez de redonner vos classes au projet, rappelez-vous qu'il est d'une importance primordiale pour le JRE émulé que chaque classe incluse suive la même sémantique que le JRE Java d'origine. Cela garantit que n'importe qui peut recompiler le code Java en JavaScript et avoir confiance qu'il obtiendra les résultats attendus. Assurez-vous toujours que votre code est soigneusement testé avant de le rendre à la communauté.

Couche d'interopérabilité

Pour être un outil efficace pour la production d'applications Web réelles, GWT doit permettre aux développeurs d'interagir facilement avec la plate-forme sous-jacente. C'est-à-dire le navigateur et le DOM.

Dès le début, GWT a été conçu pour prendre en charge une telle interaction via l'interface JavaScript native (JSNI), ce qui facilite l'accès aux API dans le navigateur. Par exemple, en utilisant les fonctionnalités de syntaxe propres au compilateur GWT, vous pouvez écrire le code Java suivant :

 public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;

et vous êtes libre d'implémenter le corps de la méthode en JavaScript. Vous pouvez même envelopper des objets JavaScript dans un JavaScriptObject (JSO) et le rendre accessible dans votre code Java.

Un exemple de l'endroit où cette couche entre en jeu peut être trouvé dans le contexte de la composition de l'interface utilisateur. Mainstream Java a toujours utilisé la boîte à outils Widgets standard pour créer des éléments d'interface utilisateur, en tirant parti de l'interface native Java pour accéder aux systèmes de fenêtrage et d'entrée du système d'exploitation sous-jacent. La couche d'interopérabilité de GWT fait la même chose, de sorte que les widgets traditionnels fonctionnent de manière transparente dans le navigateur. La seule différence est que, dans ce cas, le système sous-jacent est le navigateur et le DOM.

Cependant, les frameworks frontaux natifs se sont rapidement améliorés ces dernières années et offrent aujourd'hui des avantages significatifs par rapport aux widgets de GWT. Au fur et à mesure que ces frameworks sont devenus plus sophistiqués, les tentatives de les mettre en œuvre dans le JSNI ont révélé des lacunes dans l'architecture de la couche d'interopérabilité. À partir de la version 2.7, GWT a introduit JsInterop, une nouvelle approche basée sur les annotations Java, qui vous permet d'intégrer rapidement et facilement vos classes GWT avec JavaScript. Il n'est plus nécessaire d'écrire des méthodes JSNI ou des classes JSO. Au lieu de cela, vous pouvez simplement utiliser des annotations telles que @JSType ou @JSProperty , ce qui vous permet de travailler avec des classes JavaScript natives comme s'il s'agissait de Java.

La spécification complète de JsInterop est toujours en cours et les dernières mises à jour ne peuvent être testées qu'en compilant la source à partir du référentiel GWT. Mais il est déjà clair que c'est cette nouvelle direction qui permettra à GWT de suivre l'évolution des plateformes Web.

Un projet en cours tirant parti de JsInterop est le gwt-polymer-elements récemment publié, qui met tous les éléments de fer et de papier de Polymer à la disposition de GWT. Ce qui est intéressant dans cette bibliothèque, c'est que les développeurs n'ont pas besoin de générer l'API Java à la main. Le projet utilise gwt-api-generator pour générer la plupart des interfaces directement en analysant la bibliothèque Polymer et les annotations JSDoc. Cela facilite la mise à jour des reliures.

Derniers mots

Avec les améliorations apportées au compilateur, à la couche d'interopérabilité, ainsi qu'aux performances et à la taille du code généré au cours des deux dernières années, il est clair que GWT n'est pas simplement "un autre outil de développement Web", mais est en passe de devenir une boîte à outils de référence majeure pour le développement d'applications Web complexes à grande échelle, et pourrait même être un excellent choix pour rendre les applications plus simples géniales.

J'utilise GWT quotidiennement dans mon travail de développeur et de consultant, mais j'aime surtout GWT car il me permet de repousser les limites des capacités du navigateur et de montrer que les applications Web modernes peuvent être aussi puissantes que les applications de bureau.

La communauté du projet GWT est très active et de nouvelles bibliothèques, projets et applications basés sur GWT sont constamment proposés. À Florence, la communauté GWTcon2015 se réunira le 11 novembre. Si vous êtes dans la région, j'espère que vous viendrez rencontrer certains des principaux développeurs et découvrirez toutes les opportunités de faire partie de l'évolution de cette incroyable boîte à outils.