Retour sur la réunion de travail GWT 2015 à Google

Il y a eu des changements dans la spécification, qui est d'ailleurs toujours en mouvement. Mais le tout est dans un état de finalisation.

GWT est en fait tant de choses. C'est :

• un transpileur ;
• un optimiseur de code JavaScript ;
• un processeur d'annotation ;
• un système de build ;
• un environnement runtime ;
• une bibliothèque UI.

En fait, GWT supporte une complexité trop importante, surtout si l'on considère les outils standards qui existent par ailleurs et qui pourraient prendre le relais. Par exemple APT peut prendre le relais sur les générateurs. Pour les systèmes de build, il y a Maven, Gradle, Bazel… Pour les permutations, il y a le nouveau System.getProperty().

Il faut également adapter la sortie du compilateur GWT aux futurs modules ES6. Et faire levier sur le compilateur Closure compiler. En faisant la comparaison, on s'est rendu compte que si on désactivait les optimisations faites par gwt, Closure produisait des fichiers js de taille équivalente. Il est donc peu risqué de désactiver les optimisations GWT et laisser le travail à Closure.

Par ailleurs, il faudra aussi faire levier sur les API des navigateurs (à travers elemental, jsinterop et definitely typed).

Pour compiler le Java, pourraient être utilisés JDT ou Javac. Ou bien on pourrait écrire un compilateur de zéro, mais trop long.

Donc l'architecture serait plutôt :

• JDT comme processeur et générateur d'AST ;
• transformation en AST GWT ;
• transpilation immédiate en JavaScript.

C'est tout !

Comme vous le constatez, l'architecture est réduite à son strict minimum. Ce qui pour moi montre que l'équipe GWT a su extraire l'essence de GWT et qu'elle a su tirer les leçons du passé. Tout ceci montre que l'avenir de GWT est entre de bonnes mains.

Les choix ici sont critiques quant à la qualité des fichiers JavaScript générés. Heureusement, l'équipe dispose d'ores et déjà de benchmarks qui permettront de bien évaluer les décisions architecturales prises.

• Rédaction de l'ensemble des sémantiques Java, de façon à implémenter rapidement quelque chose qui implémente la sémantique Java.
• Un sous-ensemble de la JRE doit être émulé. On utilisera sûrement une version modifiée de la couche d'émulation actuelle.
• IO et Thread seront toujours proscrits. Pour la réflexion, la décision n'est toujours pas prise. Peut-être un sous-ensemble de l'API de réflexion ? Le sujet reste ouvert, mais ce qui est sûr c'est que ce sujet a un impact très important sur les performances.
• Une API DOM minimale.
• JsInterop. Une bonne partie de la logique de JsInterop existe déjà dans Closure et pourrait donc lui être déléguée.
• Intégration avec Bazel.

En termes de performances, voici les objectifs fixés :

• taille des fichiers générés. En générant du code JavaScript compréhensible par Closure, la taille des fichiers générés est estimée à 25 % en dessous de ce qui est généré actuellement avec GWT ;
• vitesse d'exécution. En fait au lieu d'optimiser le JavaScript, le mieux est d'éviter de perturber les VM JavaScript (ce qui est le cas avec les optimisations faites par le GWT actuel). La politique d'optimisation GWT change fait donc un virage à 180° !;
• rapidité du transpileur. Cela doit être comparable à la compilation Java à la volée dans Eclipse, c'est-à-dire imperceptible.

Aujourd'hui on utilise <replace-with>. Mais ceci va complètement disparaitre. À la place il faudra écrire (par exemple) :

private static HistoryImpl impl = createImpl();

private static HistoryImpl createImpl()
{
    String userAgent = System.getProperty("user.agent");
    return "ie8".equals(prop) ?
        new HistoryImplIE8() :
        new HistoryImpl();
}

Ceci est tout à fait équivalent ! Et cela permet de déléguer la problématique des permutations au build system.

Notez que l'implémentation de System.getProperty() sera disponible en GWT 2.8, donc les applications auront la possibilité de se préparer en avance de phase au passage à la version 3.0 !

Ce nouveau paradigme aura l'avantage de vous permettre de grouper vos permutations à votre guise.

Les générateurs posent problème :

• « Donne-moi toutes les classes qui implémentent l'interface X » est le genre de question que l'on peut poser au sein d'un générateur GWT. Mais ceci pose trop de problèmes pour écrire un compilateur incrémental.

APT qui est un standard Java propose pratiquement les mêmes fonctionnalités. Certes l'API d'APT n'est pas la panacée, mais certains projets peuvent aider dans ce sens : google auto, dagger, dagger 2, immutables, hexa.binding.

Quelques problèmes néanmoins avec APT :

• l'API n'est pas terrible (c'est le moins que l'on puisse dire, et de ma propre expérience je confirme !) ;
• si le générateur APT utilise une ressource, il n'est pas déclenché si cette ressource est modifiée, seulement quand un fichier Java est touché. Solutions possibles : avec Bazel ceci peut être pris en charge par le build system. Avec Maven, ceci prendrait quelque chose comme 10 secondes par itération : insupportable. Gradle : 3 secondes, toujours mauvais. Une solution (un serveur de dépendance) pourrait être que le générateur APT émette un fichier dans lequel il décrit tous les fichiers ressources utilisées, puis que le build system consomme ces fichiers et s'en serve pour déclencher le processeur d'annotation au bon moment.

Pour l'instant, voici les générateurs internes à GWT qui pourraient fonctionner en étant portés pour APT :

• GSS et ClientBundle ;
• I18N ;
• UiBinder ;
• SafeHtmlTemplates ;
• PlaceHistoryMapperGenerator.

Mais un générateur pose de gros problèmes : GWT RPC. Il faudrait avoir plus d'informations dans les interfaces de service pour que le générateur puisse fonctionner en mode « APT » avec les bonnes informations, sans avoir à connaitre l'ensemble de la base de code de l'application (ce qui empêche toute sorte de compilation incrémentale efficace).

GSS et I18N seront sûrement portés vers APT.

III-A-2-a. I18N▲

@Translate({"de", "fr", ...})
public interface MyTranslations // plus d'interface de marquage
{
    String hello();
}

MyTranslations instance = MyTranslations_Factory.create();

III-A-2-b. GWT RPC▲

III-A-2-c. Accès DOM▲

Le cœur est stable (on peut écrire des directives), le Singular expression language est implémenté, mais la sécurité doit être auditée.