Programmation GWT 2 : Sous le capot de GWT

Toute l'ingéniosité de GWT est d'avoir su construire un compilateur Java vers Java- Script. Un compilateur intelligent capable d'optimiser et de générer du code tout en respectant les préceptes de base du Web. Toute cette face cachée de GWT est encore très méconnue du grand public, qui, après tout, n'a pas à se soucier des implémentations internes du compilateur. Et pourtant, les vraies pépites, la vraie beauté de ce framework réside dans cette partie passionnante de GWT. Pour celui qui sait décrypter un minimum les nombreuses subtilités et configurations du compilateur, chaque fonctionnalité est une source d'inspiration unique.

Le compilateur GWT est en perpétuelle évolution car la taille du framework ne cesse d'augmenter (il suffit d'observer le nombre de nouvelles API). Les utilisateurs n'ont de cesse de réclamer des applications réactives avec des temps de chargement instantanés ; impossible dans ce contexte de s'assoir sur ses lauriers. Plus qu'une nécessité, l'amélioration du JavaScript généré par le compilateur est devenue pour chaque version une urgence vitale.

Ce chapitre explore les nombreuses facettes du compilateur GWT et aborde la structure des fichiers générés et les différentes optimisations. Un éclairage particulier est apporté au mécanisme permettant d'étendre le processus de génération pour y ajouter des traitements spécifiques.

Le compilateur de GWT est l'essence même du framework. Lorsqu'on sait la richesse des sept mille classes du JDK, on réalise que celui qui ose imaginer un jour que ce langage peut produire du code JavaScript a du génie.

Même s'il est vrai qu'il existe des similitudes entre Java et JavaScript, certaines subtilités peuvent poser problème. Java propose des classes, JavaScript des prototypes de méthodes. Java dispose d'un mécanisme d'espaces de nommage (les fameux packages), JavaScript non. Java permet d'effectuer des appels polymorphiques, ils sont plus complexes en JavaScript. Java est un langage à typage statique, JavaScript un langage à typage dynamique.

Malgré tous ces points, GWT réussit à marier ces deux langages sans briser à aucun moment leur sémantique respective.

Pour bien comprendre les subtilités du compilateur, analysons ce qu'il génère sur des cas triviaux.

I-1. Vive les fonctions JavaScript !▲

package com.dng.client;

public class Animal {
	String race ;
	public String getRace() {
		return race;
	}
	
	public void setRace(String race) {
		this.race= race;
	}

	int age ;
	
	public Animal(String race, int age) {
		super();
		this.race= race;
		this.age = age;
	}

	public void parle() {
		// En fonction de l'animal, aboie, miaule, etc.
	};
}

// Et la méthode onModuleLoad()
public class CompilateurSample {
	public void onModuleLoad() {
		Animal a = new Animal("berger allemand",2);
		a.parle();
		Window.alert(a.getRace());
	}
}

<target name="gwtc" depends="javac" description="GWT compile to JavaScript">
	<java failonerror="true" fork="true" classname="com.google.gwt.dev.Compiler">
		<classpath>
			<pathelement location="src" />
			<path refid="project.class.path" />
		</classpath>
		<jvmarg value="-Xmx256M" />
		<arg value="-style" />
		<arg value="DETAILED" />
		<arg value="-draftCompile" />
		<arg value="com.dng.CompilateurSample" />
	</java>
</target>

<script><!--
var _;
function nullMethod(){}

function $$init(){}

function $Object(this$static){
	$$init();
	return this$static;
}

function Object_0(){}
	
_ = Object_0.prototype = {};
function $$init_0(){
}

function $Animal(this$static, race, age){ // (2)
	$Object(this$static); // (3)
	$$init_0();
	this$static.race = race;
	this$static , age;
	return this$static;
}

function $getRace(this$static){ // (5)
	return this$static.race;
}

function $parle(){} // (4)

function Animal(){}

_ = Animal.prototype = new Object_0;
_.race = null;
function $$init_1(){}

function $CompilateurSample(this$static){
	$Object(this$static);
	$$init_1();
	return this$static;
}

function $onModuleLoad(){
	var a;
	a = $Animal(new Animal, 'berger allemand', 2); // (1)
	$parle();
	alert_0($getRace(a));
}

function CompilateurSample(){}

--></script>

Nous allons ici détailler les différentes étapes menant à la génération des artéfacts lors de la compilation d'un programme GWT. L'idée est ici de bien comprendre le processus d'optimisation et le modèle interne au compilateur.

GWT a besoin du code source Java.

Il y a un débat récurrent au sein des contributeurs GWT qui est celui du modèle de compilation. À l'origine, le choix a été de s'appuyer sur le code source Java pour générer le JavaScript plutôt que réutiliser le byte code. Nous ne discuterons pas ici de la pertinence de cette décision. Il faut simplement savoir que GWT a besoin du code source car il extrait certaines informations telles que le code JSNI. Une autre raison avancée par les créateurs de GWT est la possibilité d'optimiser à partir d'informations présentes uniquement dans le code source. Si on prend, par exemple, les types génériques (Class<T>), ceux-ci sont réécrits par le compilateur.

Voyons maintenant les différentes étapes intervenant lors de la compilation.

II-1. Lecture des informations de configuration▲

II-2. Création de l'arbre syntaxique GWT▲

La seconde étape consiste à parcourir récursivement l'ensemble des modules dépendant du module que l'on souhaite compiler pour construire une sorte d'arbre syntaxique en mémoire. Un arbre syntaxique est un modèle objet spécifique qui a pour but de représenter un programme source au travers des différentes structures de contrôle qui le composent.

En Java, il existe une sorte de standard dans ce domaine, le JDT (Java Development Tool) issu de l'IDE Eclipse. Comme le montre la figure suivante, il est possible de se servir du JDT pour créer un arbre syntaxique. JDT propose une API riche constituée des types IPackageFragment, ICompilationUnit, IType, IMethod, etc.

Si les concepteurs de GWT avaient fait le choix de générer du code JavaScript à partir du source Java, l'arbre JDT aurait constitué un candidat pour construire un arbre syntaxique (arbre AST) automatiquement.

Mais au lieu de cela, il a fallu créer de zéro un modèle spécifique adapté aux contraintes de GWT (fonctions JSNI, liaison différée, etc.). Lors du parcours récursif, le compilateur examine le code source Java et construit en mémoire un arbre AST de type JProgram. Le schéma suivant illustre globalement le concept : une méthode est composée d'un ou plusieurs blocs de programmes, chaque bloc est lui-même composé de variables, d'expressions ou de structures de contrôles (condition, boucle, etc.). Bref, en fin d'analyse, GWT dispose en mémoire d'un arbre (potentiellement énorme) composé de l'ensemble des modules de l'application (notez au passage l'intérêt de réduire les dépendances).

Une fois cet arbre construit (qu'on nomme arbre « unifié », car il n'est lié à aucune permutation), le compilateur réalise une précompilation. C'est-à-dire qu'il substitue et génère toutes les classes Java à partir des règles définies dans les métadonnées (substitution de classe, génération de code, etc.), l'objectif étant d'obtenir un arbre syntaxique unifié auquel on accole des sous-arbres spécifiques. Notez que, lors de cette opération, des optimisations interviennent déjà car certaines règles peuvent conduire à des permutations semblables.

GWT ne génère pas de permutations d'arbre
À aucun moment, GWT ne génère n permutations en mémoire d'un arbre syntaxique ; ce serait trop lourd à gérer d'un point de vue des performances. Il crée un seul arbre AST unifié puis lui associe des métadonnées correspondant aux différentes règles de substitution.

Une fois ces conditions réunies, la compilation Java vers JavaScript proprement dite peut commencer.

II-3. La génération de code JavaScript et les optimisations▲

public static PermutationResult compilePermutation(..., int permutationId){
	long permStart = System.currentTimeMillis();
	AST ast = unifiedAst.getFreshAst();
	(...)
	// Remplace tous les GWT.create() et génère le code JavaScript
	ResolveRebinds.exec(jprogram, rebindAnswers);

	// Optimise un peu (plus rapide) ou beaucoup (forcément plus lent)
	if (options.isDraftCompile()) {
		draftOptimize(jprogram);
	} else {
		// Presse le citron de l'optimisation jusqu'à ne plus pouvoir gagner d'octet
		do {
			boolean didChange = false;

			// Enlève tous les types non référencés, champs, méthodes, variables…
			didChange = Pruner.exec(jprogram, true) || didChange;
			// Rend tout "final", les paramètres, les classes, les champs, les méthodes
			didChange = Finalizer.exec(jprogram) || didChange;
			// Réécrit les appels non polymorphiques en appels statiques
			didChange = MakeCallsStatic.exec(jprogram) || didChange;

			// Supprime les types abstraits
			// - Champs, en fonction de leur utilisation, change le type des champs
			// - Paramètres : comme les champs
			// - Paramètres de retour de méthode : comme les champs
			// - Les appels de méthodes polymorphiques : dépend de l'implémentation
			// - Optimise les conversions et les instanceof
			didChange = TypeTightener.exec(jprogram) || didChange;

			// Supprime les types abstraits lors des appels de méthode
			didChange = MethodCallTightener.exec(jprogram) || didChange;
		
			// Supprime les éventuelles portions de code mort
			didChange = DeadCodeElimination.exec(jprogram) || didChange;
			
			if (isAggressivelyOptimize) {
				// On supprime les fonctions en déplaçant leur corps dans l'appelant
				didChange = MethodInliner.exec(jprogram) || didChange;
			}
		} while (didChange);
	}
	
	(...)

	// Generate a JavaScript code DOM from the Java type declarations
	(...)
	JavaToJavaScriptMap map = GenerateJavaScriptAST.exec(jprogram, jsProgram,
		options.getOutput(), symbolTable);
		
	// Réalise cette fois des optimisations JavaScript
	if (options.isAggressivelyOptimize()) {
		boolean didChange;
		do {
			didChange = false;
			// Supprime des fonctions JavaScript inutilisées, possible
			didChange = JsStaticEval.exec(jsProgram) || didChange;
			// Inline JavaScript function invocations
			didChange = JsInliner.exec(jsProgram) || didChange;
			// Remove unused functions, possible
			didChange = JsUnusedFunctionRemover.exec(jsProgram) || didChange;
		} while (didChange);
	}

	// Permet de créer une pile d'appels pour simuler la StackTrace Java
	JsStackEmulator.exec(jsProgram, propertyOracles);

	// Casse le programme en plusieurs fragments JavaScript
	// (aka CodeSplitting)
	SoycArtifact dependencies = splitIntoFragment(logger, permutationId,
		jprogram, jsProgram, options, map);

	// Réalise l'opération d'obfuscation (OBFS, PRETTY, DETAILED
	Map<JsName, String> obfuscateMap = Maps.create();
	switch (options.getOutput()) {
		case OBFUSCATED: (...)
		case PRETTY: (...)
		case DETAILED: (...)
	}

	// Génère le rendu final au format texte.
	PermutationResult toReturn = generateFinalOutputText(logger, permutationId,
		jprogram, jsProgram, options, symbolTable, map, dependencies,
		obfuscateMap, splitBlocks);
	System.out.println("Permutation took "
		+ (System.currentTimeMillis() - permStart) + " ms");
	return toReturn;
}

public class Animal {
	String race ;
	int age ;
	public String getRace() {
		return race;
	}
	
	public void setRace(String race) {
		this.race= race;
	}
	
	public int getAge() {
		return age;
	}
	
	public void setAge(int race) {
		this.age= age;
	}
	
	public Animal(String race, int age) {
		super();
		this.race= race;
		this.age = age;
	}
	
	public void parle() {
		// En fonction de l'animal, aboie, miaule, etc.
	};
}

// Classe onModuleLoad()
public class CompilateurSample implements EntryPoint {

	public void onModuleLoad() {
		Animal a = new Animal("berger allemand",2);
		Window.alert(a.getRace());
	}
}

_ = Object_0.prototype = {};
function $Animal(this$static, race){
	this$static.race = race;
	return this$static;
}

function Animal(){}

_ = Animal.prototype = new Object_0;
_.race = null;

function init(){
	var a;
	a = $Animal(new Animal, 'berger allemand');
	$wnd.alert(a.race);
}

// Code Java
Animal instance = new Animal();
instance.parle()
// Est transformé en JavaScript par
function $Animal(instance){
	parle(instance);
}
function parle(instance){
	(...)
}

Forme f = new Carre(2);
int a = f.getSurface()
// Devient via le jeu de l'inlining
Forme f = new Carre(2);
int a = f.length * f.length;
// Puis
int a = 4;

Le compilateur fournit une option très intéressante permettant de tracer les différentes optimisations observées sur une méthode. Le mode de trace s'utilise en pointant le nom d'une méthode de la manière suivante :

java com.google.gwt.dev.compiler -Dgwt.jjs.traceMethods=com.dng.sample.onModuleLoad
com.dng.CompilateurSample

Voici pour un exemple donné, le type d'affichage produit par l'option de trace.

public abstract class Animal {
	String race;
	int age;

	public int getAge() {
		return age;
	}
	
	public void setAge(int age) {
		this.age = age;
	}

	public Animal() { }
	
	public Animal(String race, int age) {
		this.race = race;
		this.age = age;
	}

	public abstract String getRace();
}

public class Chien extends Animal {
	String race = "BERGER ALLEMAND";
	
	@Override
	public String getRace() {
		return race;
	}
}

public class CompilateurSample implements EntryPoint {
	
	public void onModuleLoad() {
		Animal a = new Chien();
		String race = a.getRace();
		Window.alert("La race du client est " + race);
	}
}

// La compilation génère la trace suivante avec l'option activée

	JAVA INITIAL:
	---------------------------
	public void onModuleLoad(){
		Animal a = (new Chien()).Chien();
		String race = a.getRace();
		Window.alert("La race du client est " + race);
	}
	---------------------------
	FinalizeVisitor:
	---------------------------
	public final void onModuleLoad(){
		final Animal a = (new Chien()).Chien();
		final String race = a.getRace();
		Window.alert("La race du client est " + race);
	}
	---------------------------
	JAVA INITIAL:
	---------------------------
	public static final void $onModuleLoad(CompilateurSample this$static){
		final Animal a = (new Chien()).Chien();
		final String race = a.getRace();
		Window.alert("La race du client est " + race);
	}
	(...)
	---------------------------
	TightenTypesVisitor:
	---------------------------
	public static final void $onModuleLoad(CompilateurSample this$static){
		final Chien a = Chien.$Chien(new Chien());
		final String race = a.getRace();
		Window.alert("La race du client est " + race);
	}
	---------------------------
	PruneVisitor:
	---------------------------
	public static final void $onModuleLoad(){
		final Chien a = Chien.$Chien(new Chien());
		final String race = a.getRace();
		Window.alert("La race du client est " + race);
	}
	---------------------------
	RewriteCallSites:
	---------------------------
	public static final void $onModuleLoad(){
		final Chien a = Chien.$Chien(new Chien());
		final String race = Chien.$getRace(a);
		Window.alert("La race du client est " + race);
	}
	---------------------------
	InliningVisitor:
	---------------------------
	public static final void $onModuleLoad(){
		final Chien a = (((()), new Chien()));
		final String race = (("BERGER ALLEMAND"));
		Window.alert("La race du client est " + race);
	}
	---------------------------
	DeadCodeVisitor:
	---------------------------
	public static final void $onModuleLoad(){
		final Chien a = new Chien();
		final String race = "BERGER ALLEMAND";
		Window.alert("La race du client est BERGER ALLEMAND");
	}
	---------------------------
	CleanupRefsVisitor:
	---------------------------
	public static final void $onModuleLoad(){
		new Chien();
		"BERGER ALLEMAND";
		Window.alert("La race du client est BERGER ALLEMAND");
	}
	---------------------------
	DeadCodeVisitor:
	---------------------------
	public static final void $onModuleLoad(){
		Window.alert("La race du client est BERGER ALLEMAND");
	}

Le compilateur GWT est assez riche et ses options (comme la précédente) plutôt méconnues du grand public. La version 2 apporte son lot de nouveautés avec l'introduction du mode draftCompile et les rapports de compilation.

L'option -extra permet de générer des fichiers non déployés en production et contenant diverses informations.

• Répertoire rpcPolicyManifest : un fichier de policy est un fichier de métadonnées détaillant l'ensemble des types RPC utilisés dans un module. Le fichier rpcPolicyManifest précise pour plusieurs modules les chemins relatifs de leur fichier de policy respectifs.
• Répertoire symbolMaps : contient une table de correspondances permettant de retrouver une classe à partir de son nom obfusqué dans le fichier JavaScript. Cette table sert essentiellement à l'affichage de la pile d'appels en cas d'erreur. Ce sujet est couvert en fin de chapitre.

Notez que l'option \x{0096}compileReport génère également des artéfacts dans le répertoire war par défaut.

En plus des arguments classiques du compilateur, GWT utilise des propriétés système pour certaines opérations avancées telles que le paramétrage des traces ou la suppression des messages d'avertissement. Le tableau suivant illustre ces options système.

Vu la complexité des optimisations et le mode de fonctionnement du compilateur, ce n'est pas une surprise si l'une des préoccupations majeures des développeurs GWT concernent les temps de compilation. Avec GWT 2 et la possibilité de tester le code à partir d'un vrai navigateur, cette contrainte ne devrait plus réellement constituer un facteur de blocage. En effet, dans cette version, la compilation réelle n'intervient que pour valider définitivement le rendu visuel d'une application.

Malgré tout, il existe plusieurs optimisations possibles, dont certaines ont été abordées dans le chapitre sur la liaison différée.

1. Réduire le nombre de permutations : GWT est paramétré par défaut pour générer 6 permutations (une par navigateur). Si on sait que seuls IE 7 et Firefox 3 seront supportés, il suffit de définir la propriété user.agent de la manière suivante dans le fichier de configuration du module : <set-property name="user.agent" value="ie6,gecko" />. Ce paramétrage réduit en moyenne de 50 % les temps de compilation.
2. Ajouter l'option -draftCompile lors de la compilation : en phase de développement les gains peuvent aller de 5 à 30 % en fonction des scénarios.
3. Donner une valeur à l'argument -localWorkers : GWT 1.5 a introduit la notion de worker pour la compilation. Pour une machine bi-coeur (Dual Core), une valeur paramétrée à 2 permet de paralléliser la compilation des permutations sur chaque coeur. Le gain est en moyenne de 10 %. Ce chiffre s'améliore progressivement dans le cas d'une machine à 4 coeurs (Quad Core).
4. Configurer la JVM avec des paramètres adaptés : pour une application moyenne, les options suivantes permettent d'assurer suffisamment de mémoire, une taille de pile cohérente et un espace de stockage temporaire adapté.

java com.google.gwt.dev.Compiler -Xmx512M -Xss128k -Xverify:none -X:PermSize=32m Module

Comme exposé précédemment, le processus de déploiement de GWT fait intervenir un certain nombre d'étapes. La compilation génère des fichiers de permutation placés dans un sous-répertoire du contexte web racine de l'application. Une fois la page hôte appelée, un script de sélection est exécuté réalisant dans la foulée le chargement de la permutation correspondant aux propriétés du navigateur.

Si ce mode de fonctionnement convient dans la majeure partie des cas, il est quelquefois utile de s'insérer dans le processus de génération des fichiers pour y apporter quelques modifications. Imaginez par exemple un site GWT déployé sous la forme d'un portlet ou un gadget GWT proposant des métadonnées avec un point d'entrée spécifique. De simples contraintes de déploiement (DMZ, répertoires spécifiques par ressources, etc.) requièrent parfois la modification des fichiers générés par GWT. Dans l'exemple suivant, qui représente le contrat d'un gadget GWT, la méthode d'initialisation n'est pas onModuleLoad() mais init() :

@ModulePrefs(
	title = "Gadget GWT",
	directory_title = "Mon gadget GWT ",
	screenshot = "gadget.png",
	thumbnail = "thumb.png",
	...
	height = 210)
public class MyGWTGadget extends Gadget<MyGWTGadgetPreferences>
{
	public void onModuleLoad() { }
	// Remplacé par la méthode d'initialisation suivante
	protected void init(
	final MyGWTGadgetPreferences prefs) {
		...
	}
}

Voici la séquence d'appel des différentes composantes de la construction GWT. À chaque étape correspond un ensemble d'artéfacts générés ou compilés (les fichiers ou morceaux de code source).

L'idée sous-jacente aux linkers est de permettre au développeur d'interférer dans le mécanisme de construction et d'édition des différents liens pour y apporter un traitement spécifique.

Il faut savoir que GWT propose par défaut cinq linkers définis dans le module Core.gwt.xml situé dans le fichier gwt-user.jar.

• Le SingleScriptLinker : utilisé lorsqu'on souhaite générer un seul fichier Java-Script pour un module. Cela suppose qu'il n'existe qu'une seule permutation.
• Le XSLinker : utilisé lorsque le serveur hébergeant les permutations est différent de celui hébergeant la page hôte. Ce linker produit des fichiers d'extension xs comme <module>-xs.nocache.js.
• Le IFrameLinker : c'est le linker principal utilisé par GWT, il génère une IFrame cachée.
• Le SymbolMapLinker : ce linker se charge de créer un fichier de correspondances permettant d'afficher des piles d'erreurs pointant des noms de variables non obfusquées.
• Le SoycReportLinker : les rapports de compilation constituent l'historique de la compilation ; ce linker restitue des fichiers de traces contenant des métriques liées aux optimisations.

Voici un extrait de fichier de configuration (tiré du code source de GWT) illustrant la déclaration d'un linker et son ajout dans le projet courant.

<module>
	<inherits name="com.google.gwt.dev.jjs.intrinsic.Intrinsic" />
	(...)
	<super-source path="translatable" />
	
	<define-linker name="sso"
	class="com.google.gwt.core.linker.SingleScriptLinker" />
	<define-linker name="std" class="com.google.gwt.core.linker.IFrameLinker" />
	<define-linker name="xs" class="com.google.gwt.core.linker.XSLinker" />
	
	<define-linker name="soycReport" class="com.google.gwt.core.linker.SoycReportLinker" />
	<define-linker name="symbolMaps" class="com.google.gwt.core.linker.SymbolMapsLinker" />
	
	<add-linker name="std" />
	
	<add-linker name="soycReport" />
	<add-linker name="symbolMaps" />
</module>

Ces linkers s'exécutent dans un ordre déterminé par trois états : avant (LinkOrder.PRE), pendant (LinkOrder.PRIMARY) et après (LinkOrder.POST).

À titre d'exemple, le linker standard (IFrameLinker) qualifié dans le fichier Core.gwt.xml"std" est un linker primaire, c'est-à-dire qu'il s'exécute de manière autonome et produit un script de sélection chargeant les permutations dans une IFrame cachée. Sa seule dépendance est celle liée à son héritage. IFrameLinker, au même titre que la plupart des linkers primaires dérivent de la classe SelectionScriptLinker qui lui offre la génération du script de sélection. Il est bien évidemment possible de redéfinir à tout moment le comportement des linkers prédéfinis.

1. Créer une classe dérivant de com.google.gwt.core.ext.Linker.
2. Ajouter l'annotation @LinkOrder pour déterminer si le linker doit s'exécuter avant, après ou en remplacement du linker primaire. Le nombre de linkers n'est pas limité, seul le primaire est unique.
3. Définir et ajouter le linker personnalisé dans le fichier de configuration du module (<module>.gwt.xml).
4. Inclure dans le classpath du compilateur le nouveau linker.

Le linker suivant répertorie dans une chaîne de caractères l'ensemble des artéfacts générés par le compilateur (permutation, images, etc.) suivi de la date de dernière modification. Il ajoute ensuite un nouvel artéfact (un nouveau fichier) contenant cette chaîne. L'objectif est de montrer ici un linker simple qui extrait des informations du compilateur et crée de nouveaux fichiers en sortie.

package com.dng.linkers;

import java.util.Date;
import com.google.gwt.core.ext.LinkerContext;
import com.google.gwt.core.ext.TreeLogger;
import com.google.gwt.core.ext.UnableToCompleteException;
import com.google.gwt.core.ext.linker.AbstractLinker;
import com.google.gwt.core.ext.linker.Artifact;
import com.google.gwt.core.ext.linker.ArtifactSet;
import com.google.gwt.core.ext.linker.EmittedArtifact;
import com.google.gwt.core.ext.linker.LinkerOrder;

@LinkerOrder(LinkerOrder.Order.POST)
public class MyLinker extends AbstractLinker {

	public String getDescription() {
		return "MyLinker";
	}

	public ArtifactSet link(TreeLogger logger, LinkerContext context,
			ArtifactSet artifacts) throws UnableToCompleteException {
		String artifactList="";
		// Récupère la liste de tous les artéfacts
		ArtifactSet toReturn = new ArtifactSet(artifacts);
		for (Artifact artifact : toReturn) {
			// Et trie seulement les fichiers générés
			if (artifact instanceof EmittedArtifact) {
				EmittedArtifact fic = (EmittedArtifact) artifact;
				// Stocke dans une chaîne de caractères le nom du fichier généré
				artifactList = fic.getPartialPath() + "," + new
				Date(fic.getLastModified()).toString() + "\n" + artifactList ;
			}
		}
		// Ajoute à la liste précédente un nouveau fichier recensant
		// les artéfacts
		toReturn.add(emitString(logger, artifactList, "ListFiles.txt"));
	
		return toReturn;
	}
}

L'exécution du code précédent produit la sortie suivante.

La méthode link() est appelée par le compilateur qui lui transmet le paramètre ArtifactSet, une collection de l'ensemble des artéfacts du module. Notez qu'un artéfact n'est pas nécessairement un fichier physique généré dans le répertoire de destination du module. Seules les ressources de type EmittedArtifact sont destinées à être générées.

• la résultante d'une compilation (CompilationResult) contenant en mémoire des informations de permutation (flux JavaScript, clé MD5, etc.) ;
• les fichiers physiques (EmittedArtifact) générés dans le répertoire de sortie du module ( JavaScript, CSS, etc.) ;
• l'analyse de compilation (utilisée ensuite par les rapports de compilation).

Il est possible à tout moment de s'intercaler dans le processus de génération pour modifier ces artéfacts. Différentes méthodes sont fournies dont certaines permettant de lire le JavaScript généré, de le modifier ou simplement d'ajouter certaines informations.

Au-delà du simple recensement d'artéfacts, il existe de nombreux scénarios d'utilisation des linkers. On pourrait ainsi imaginer un linker qui se chargerait de télécharger des fichiers sur un serveur FTP distant en cas de compilation. Ou un autre qui aurait pour objectif de déplacer les fichiers statiques dans un répertoire donné (.cache.html) et les fichiers dynamiques (éventuelles pages JSP) dans un autre répertoire.

Autre exemple, dans le cas où une seule permutation est générée (comme pour un mobile IPhone ou Android), on pourrait imaginer un linker qui optimiserait les permutations pour embarquer le script de sélection et la permutation au sein du même fichier. Cela épargnerait une requête HTTP supplémentaire pour charger la permutation.

Bref, le procédé est relativement souple pour permettre tous types de personnalisation.

Java possède un mécanisme nommé la pile d'erreurs ou « StackTrace » qui fournit à l'utilisateur des données très précieuses sur le contexte d'une exception. Ces informations contiennent des informations sur la pile d'exécution (quelle méthode a été appelée avant l'erreur) ou le numéro de ligne incriminé et la nature de l'exception. Malheureusement, lorsqu'il s'agit d'exception dans le monde JavaScript, les choses peuvent vite virer au cauchemar tant il existe d'implémentations différentes en fonction des navigateurs.

Ainsi, Firefox fournit une propriété exception.stack contenant le message, le nom de fichier et la ligne. Opera intègre dans le message ces trois informations et requiert une analyse de la chaîne de caractères pour extraire un format exploitable. Quant aux autres navigateurs, ils ne proposent tout bonnement rien de très évolué dans ce domaine à part le type arguments et ses propriété arguments.callee et arguments.caller.callee.

Voici à titre d'exemple un code JavaScript utilisant err.stack :

<html>
	<head>
		<script type="text/javascript">

			function fonc1() {
				try { 
					var i = null;
					i.toto();
				}
				catch(err) {
					window.alert(err.message + "\n" + err.stack)
				}
			}
			
			function fonc2() {
				fonc1();
			}
			
		</script>
	</head>
	<a href="#" onClick="fonc1()">Génère exception </a>
</body>
</html>

Le résultat sous IE 8, Firefox 3.5, Opera, Safari et Chrome est sans équivoque et démontre la difficulté d'une gestion commune en JavaScript.

Le comportement des exceptions en production est aléatoire et surtout peu explicite (c'est évidemment un doux euphémisme). Pour s'en convaincre voici une copie d'écran d'une exception générée manuellement.

Vous aurez compris que le mécanisme d'obfuscation est le coupable de ces hiéroglyphes. En renommant systématiquement les méthodes et variables à des fins d'optimisation, GWT perd forcément en expressivité. On perd également au passage les numéros de lignes concernées par la pile.

Tout l'intérêt de GWT va consister à fournir le socle permettant d'unifier (via la liaison différée) la pile d'appels et la gestion des erreurs. Ce procédé s'appelle « l'émulation de la pile » et fait partie des nouveautés de GWT 2.

L'activation de cette fonctionnalité s'effectue en positionnant à vrai la propriété compiler.emulatedStack déjà présente dans le noyau de GWT au travers du module com.google.gwt.core.EmulateJsStack.

<module>
	<inherits name='com.google.gwt.user.theme.standard.Standard'/>
	<set-property name="compiler.emulatedStack" value="true" />
	(...)
</module>

Une fois l'émulation activée, les exceptions deviennent comme par magie beaucoup plus explicites. Seuls les noms de méthodes restent cryptés. Voici un code Java levant une exception lors d'un appel natif : voyons le résultat en termes de restitution en mode production dans un navigateur.

public void onModuleLoad() {
	try {
		fonc1();
	} catch (Exception e) {
		Window.alert(printStackTrace(e));
	}
}

private String printStackTrace(Throwable e) {
	StringBuffer msg = new StringBuffer();
	msg.append(e.getClass() + ":" + e.getMessage() + "\n");
	for (StackTraceElement se : e.getStackTrace()) {
		msg.append("at " + se.getClassName() + "."
			+ se.getMethodName() + "(" + se.getFileName() + ":"
			+ se.getLineNumber() + ")\n");
	}
	return msg.toString();
}

public void fonc1() {
	fonc2();
}

private native void fonc2() /*-{
	// L'erreur a lieu ici
	func.toto();
}-*/;

L'erreur est générée dans la fonction fonc2() elle-même appelée par fonc1(). Excepté les noms des méthodes, les numéros de lignes et les noms des fichiers source sont cohérents.

Il est fort probable qu'à l'avenir GWT propose un mécanisme permettant de traduire une pile d'appels obfusquée via un appel RPC ou une API spécifique. En attendant, le plus simple est d'activer le mode Pretty avec pour résultat de magnifiques piles.

VII-1. Table des symboles▲

# { 3 }
# { 'user.agent' : 'gecko1_8' }
# jsName, jsniIdent, className, memberName, sourceUri, sourceLine
ow,,boolean[],,Unknown,0
pw,,byte[],,Unknown,0
qw,,char[],,Unknown,0
L,,com.dng.client.AsyncSample,,file:/C:/java/projects/AsyncSample/src/
com/dng/client/AsyncSample.java,14
S,com.dng.client.AsyncSample::$clinit()V,com.dng.client.AsyncSample,$cl
init,file:/C:/java/projects/AsyncSample/src/com/dng/client/
AsyncSample.java,14
T,com.dng.client.AsyncSample::$onModuleLoad(Lcom/dng/client/
AsyncSample;)V,com.dng.client.AsyncSample,$onModuleLoad,file:/C:/java/
projects/AsyncSample/src/com/dng/client/AsyncSample.java,16
U,,com.dng.client.AsyncSample$1,,file:/C:/java/projects/AsyncSample/
src/com/dng/client/AsyncSample.java,18
V,com.dng.client.AsyncSample$1::$clinit()V,com.dng.client.AsyncSample$1
,$clinit,file:/C:/java/projects/AsyncSample/src/com/dng/client/
AsyncSample.java,18
W,,com.dng.client.CRMScreen,,file:/C:/java/projects/AsyncSample/src/
com/dng/client/CRMScreen.java,6
X,com.dng.client.CRMScreen::$clinit()V,com.dng.client.CRMScreen,$clinit
,file:/C:/java/projects/AsyncSample/src/com/dng/client/CRMScreen.java,6
Y,com.dng.client.CRMScreen::$show(Lcom/dng/client/
CRMScreen;)V,com.dng.client.CRMScreen,$show,file:/C:/java/projects/
AsyncSample/src/com/dng/client/CRMScreen.java,7
Z,,com.google.gwt.animation.client.Animation,,jar:file:/C:/gwthack/
trunk/build/dist/gwt-0.0.0/gwt-user.jar!/com/google/gwt/animation/
client/Animation.java,28
cb,com.google.gwt.animation.client.Animation::$$init(Lcom/google/gwt/
animation/client/
Animation;)V,com.google.gwt.animation.client.Animation,$$init,jar:file:
/C:/gwthack/trunk/build/dist/gwt-0.0.0/gwt-ser.jar!/com/google/gwt/
animation/client/Animation.java,28

• Consultez la table des matières complète ainsi que l'avant propos du livre
• L'ouvrage complet sur Amazon.fr
• Discussion autour de l'ouvrage "Programmation GWT 2 - Développer des applications RIA et Ajax avec GWT"
• Le forum d'entraide francophone sur GWT