Conjectures et réfutations

Karl Popper est un philosophe des sciences ayant fait des apports majeurs à l’épistémologie, avec entre autres sa définition de la démarche scientifique par la réfutabilité. Je me suis amusé à appliquer certaines de ses thèses à la mise au point de programmes, en supposant qu’un programme soit une connaissance objective au même titre qu’un théorème ou qu’une théorie scientifique.

Si on applique ces thèses, on peut démontrer que la lecture du code source ne suffit pas, par la seule puissance de la déduction, à prouver que le programme est correct. D’ailleurs, un test ne peut pas prouver la validité d’un programme, au contraire, il ne peut que mettre en évidence une erreur. Popper démontre que le raisonnement inductif n’est pas la méthode rationnelle pour se rapprocher de la vérité, mais que nous procédons par conjectures et réfutations. Tout raisonnement fonctionnerait à partir de théories que l’on essaie de contredire, par l’expérimentation ou par la logique. Pour valider un programme on cherche à le mettre en défaut, ce qui est pourtant intuitivement l’inverse du résultat visé.

Je vois donc la programmation comme l’ajout de conjectures sur un fond initial (langage de programmation employé, librairies, système d’exploitation, autres applications). Fond qui, en passant, est également réfutable selon Popper, contredisant les philosophes affirmant que tout raisonnement rationnel ne se fait qu’à partir d’une base de vérités que l’on augmente par déduction.

En poussant plus loin l’analogie, le test unitaire consisterait donc à tenter de réfuter la conjecture (le programme). Popper affirme également qu’une théorie qui en supplante une autre doit expliquer mieux ou plus de choses que la précédente mais également « survivre » aux mêmes tentatives de réfutation. C’est ce que j’appellerais les tests de non-régression.

Mais alors, si programme = conjecture et test = réfutation, que penser de cette pratique XP : « écrire systématiquement les test unitaires en premier, et ensuite seulement le programme qui va passer les tests unitaires avec succès » (le fameux Test-Driven Development) ?

En termes « popperiens » cela revient à faire des réfutations avant même de conjecturer ! Les « XPeurs » feraient-ils de la programmation d’une façon irrationnelle ?

Disons plutôt que cela signifie que la conjecture est implicite, qu’elle trotte dans la tête du programmeur (ou est discutée au sein du binôme pour ceux qui pratiquent également le « pair-programming ») pendant la programmation des réfutations/tests. Et c’est seulement une fois que toutes les réfutations sont posées que l’on rédige l’équation ou le programme. Connaissant à l’avance les tests, la programmation ressemble plus à mon avis à une sorte de régression au sens statistique (trouver la courbe qui passe par tous les points connus à l’avance).

Cela revient à peser tous les cailloux de la terre et trouver l’équation vraie pour tout un tas de cailloux donné afin de formuler la gravité. Il me semble donc à la fois plus rationnel (et plus intuitif, je l’avoue) de poser la conjecture (le programme) avant d’essayer de le réfuter (par les tests).

La connaissance objective

Là où je rejoins les partisans du test extrême c’est que la qualité d’un programme est proportionnelle à la quantité de tests tentant de le réfuter, tout comme la meilleure théorie, toutes choses égales par ailleurs, est celle qui se prête et s’est prêtée au plus de tentatives de réfutation.

Ayant moins de connaissances en philosophie qu’en informatique, il est probable que je résume mal la pensée de Popper, je vous recommande donc chaudement la lecture de l’original, comme par exemple « la connaissance objective » disponible en livre de poche.

Partager/Sauver

Un collègue m’a récemment envoyé un papier de Steven Kerr  »On the folly of rewarding A, while hoping for B« . Il montre que très souvent le discours officiel d’une organisation est de vouloir un comportement, tout en mettant en place un système de récompense/punition qui dans les faits pousse les gens à un comportement tout autre, voire opposé. Par exemple on demande à un joueur de sport collectif d’avoir « l’esprit d’équipe » et pourtant on ne félicite que les actions individuelles. D’ailleurs, on ne résume un match de football que par les noms des buteurs. Ainsi, agacé qu’un joueur fasse trop de passes à l’adversaire, un entraineur sanctionne chaque passe ratée ; au match suivant personne ne fait plus aucune passe et le jeu est bloqué.

Exemple parfait de contre-productivité : une clinique veut réduire le nombre de décès. On met donc en place une prime qui doit récompenser le chirurgien qui a moins de X décès dans le mois sur le billard. Que va-t-il se passer ? On peut parier que dans les mois suivants tous les chirurgiens vont toucher la prime… En effet, dès qu’ils s’approchent du quota fatidique, ils repoussent toutes leurs opérations délicates au mois suivant ! Du coup les gens décèdent dans leur lit en attendant l’opération, mais ça n’est pas le problème du médecin. Tout le monde touche sa prime, cependant le nombre de décès global de la clinique augmente…

Cette théorie semble être un grand classique du management (le papier remonte à 1975) mais je n’en avais jamais entendu parler. Et quand je l’ai lu j’ai eu une illumination. Tenez, imaginez que vous vous tenez sur une grande étendue de sable, une sorte de drap rouge à la main ; vous le secouez un peu en vous demandant pourquoi vous avez ça à la main , quand vous entendez un bruit de sabots tagadam-tagadam dans votre dos et *vlan*

… au génie logiciel.

J’ai compris beaucoup de choses sur le projet de développement en lisant cela.  Finalement, qu’est-ce que l’on demande aux développeurs ? Comportement ‘A’ : « Produire du code de qualité, maintenable par autrui ». Qu’est-ce que l’on récompense ? Les délais de livraison : comportement ‘B’. Je n’ai jamais vu un développeur se faire sanctionner pour du code mal écrit, non commenté ou conçu de traviole. Par contre, prenez du retard sur le développement, vous allez vous faire enguirlander et vous devrez rester tard tous les soirs pour faire bonne figure. Donc, si vous avez envie d’une vie de famille ou de loisirs : bâclez votre code. Ne commentez surtout pas, et ne testez que si l’on vous le demande. De toute façon c’est votre successeur qui sera pénalisé par le code non-maintenable ; c’est lui qui ratera ses deadlines *niark niak niak niak* (<- rire façon méchant dans James Bond).

Rendre ‘A’ inévitable, récompenser  ‘B’

On va pas chasser le naturel, alors on va biaiser un peu. Continuez à récompenser les délais (‘B’), mais considérez ‘A’ comme acquis. Il faut intégrer le contrôle qualité continu et automatisé à tout environement de développement. Il doit être impossible de réussir un « build » (et donc de livrer) si l’artefact en question ne respecte pas tous les standards en vigueur. J’ajouterai même une revue obligatoire de tout code, du stagiaire au chef de projet, avant de pouvoir placer le post-it dans la colonne « fait » du tableau blanc. Passez par la colonne « en revue », ne touchez pas vingt-mille francs. Enfin pas tout de suite… Soyons fous, récompensons la qualité .

PS: merci à Majirus pour l’article

Partager/Sauver

Ce terme est de plus en plus utilisé comme synonyme de « classe Java », ce qui est une erreur. Alors, qu’est-ce qu’un POJO au juste ? Et bien, ma définition en serait : une classe Java sans contraintes particulières.

En fait, il n’y a pas de POJO sans framework. Un framework peut vous demander de sous-classer telle ou telle classe, respecter telle convention de nommage, limiter ci, imposer cela. A l’opposé (et un peu en réaction aux EJB), on parle de POJO quand le framework justement n’impose rien sur vos classes Java : vous développez old-school, classes et interfaces sont conçues librement.

Exemple de framework pas-POJO-du-tout :

« Sous-classez com.framework.AbstractPrintableObject, avec un constructeur public à un paramètre de type com.framework.PrintEnvironment. Ne définissez que des méthodes publiques non synchronisées qui lèvent comme exceptions des sous-classes de com.framework.PrintException. etc… etc… »

Le même, façon j’aime-les-POJO :

« Passez-lui un POJO, le framework d’impression essaiera de découvrir ses getters publics et de construire une représentation textuelle imprimable. »

Je précise que j’écris ça dans un souci d’illustration, loin de moi l’idée de suggérer une quelconque supériorité d’une approche tout-POJO par rapport au framework de grand-papa qui offre un lot de superclasses abstraites. Par exemple, je trouve l’approche « pur-POJOs (ah oui, plus plein d’annotations) » un peu hypocrite…

Partager/Sauver

Partager/Sauver

La tendance en ce début d’année me semble être à la frilosité, au gel de toute forme d’investissement. On fait le dos rond pour passer la crise, même quand ses propres indicateurs sont au vert. Par exemple, prenez google, pour changer , cette entreprise se porte plutôt bien, et pourtant ça commence à dégraisser : après lively, c’est au tour de Notebook et plusieurs autres projets de passer à la trappe.

J’en déduis crise réduction des coûts, gel de tout investissement retour aux mauvaises habitudes quick-and-dirty mauvaise qualité de code.

Il va falloir, avec une réduction du budget, faire aussi bien… or, en informatique non plus il n’y a pas de magie. Les DSI vont devoir continuer à faire évoluer les systèmes, et ça se fera, comme d’habitude, en sacrifiant la qualité. On alimente ainsi une sorte de dette de maintenabilité, on vit d’une certaine manière au détriment des développement futurs. Par exemple je crois que Flex va continuer sa progression et que Flex augmente la productivité immédiate pour faire très vite des clients web sexy. Mon opinion est que Flex reste une solution qui n’encourage en rien le développement maintenable à  l’échelle du gros projet, ne serait-ce que le language actionscript. Malheureusement, la techno diamétralement opposée (non-sexytude, non-démo-immédiate, maintenabilité-nickel), soit GWT, me semble trouver peiner à trouver sa place en entreprise.

Pour résumer : les écrans sexy maintenant, et pour plus tard le développement durable (c-à-d. industrialisé et maintenable).

Lucy in the sky with diamonds

Comment réduire les coûts ? On pourrait penser qu’un élément de réponse est dans ce qu’on appelle le « cloud computing ». Pour résumer le « cloud computing » c’est de faire héberger des applications dans le nuage, vous savez, le reste du monde, le truc que l’on dessine pour figurer internet sur le diagramme qui représente votre réseau :

Rappelez-vous du slogan de Sun à une époque, « the network is the computer ». On est dans la continuité, on dirait maintenant « the internet is the computer ».

L’idée sous-jacente est que votre métier n’est (probablement) pas de faire tourner des serveurs. Alors, plutôt que de gérer des salles machines, confiez-les à ceux qui ont 1) le savoir-faire et 2) les économies d’échelle.
Citons le fondateur d’Amazon, Jeff Bezos : « We launched our Web services [...]; it’s the equivalent of creating an electric grid, but for computing. Recently, I went to Luxembourg and visited a 300-year-old brewery. It had this gigantic relic of a generator from when it had to make its own electricity. As soon as they could buy off-grid, they did. Making their own electricity didn’t make their beer taste better. It’s the same for running your own data center ». En passant, si vous pensez qu’Amazon est seulement une boutique de vente de livres en ligne, ce n’est plus du tout le cas. Entre autres innovations, Amazon se positionne à travers S3 et EC2 comme un acteur majeur du cloud computing. Disons, qu’au moins cette fois-ci il y a innovation, rappelez-vous de l’affaire du brevet « 1-click » !

Vous voyez le topo. Tout ceci concerne en premier lieu la réduction de coûts, pas vraiment l’apport de fonctionnalités nouvelles. Autre conséquence d’un gel des investissements, on ne fera pas l’investissement de passer ses applications sur le cloud : c’est une lourde ré-ingénierie, pour l’instant non maîtrisée.

J’ajoute donc passer sur le cloud demande investissement initial « le cloud, oui, mais pas cette année » désenchantement généralisé et chute du « hype » autour cloud computing. Si j’osais, je dirais sale temps pour le cloud, ha ha .

Pour toute innovation, il existerait une courbe de ‘hype’ qui serait toujours peu ou prou la même : découverte, attentes déraisonables, désenchantement et finalement compréhension puis productivité. Si vous prenez la courbe publiée par le Gartner de cet été, le cloud computing serait encore avant le « pic d’attentes exagérées ». Et bien ma prédiction est que le cloud va amorcer très vite, dès cette année, la chute des espérances qui se trouve de l’autre côté de l’à-pic. L’avenir (proche) est sombre notamment pour Amazon EC2+S3 justement. En effet, ces technos sont un formidable tremplin à startups, en fournissant un réel service d’élimination de la barrière à l’entrée d’une infrastructure web scalable. Les success-stories d’Amazon sont pour beaucoup des startups qui offrent des SaaS sur le web. Malheureusement, en cette période de crise, les startups explosent au décollage. Et les grands comptes gèlent veille et investissement. Amazon risque d’avoir du mal à atteindre son public et se constituer une clientèle. Même constat pour Google Apps Engine.

Bref, y’en a qui vont un peu trop vite en besogne.

Back in the USSR

Retour aux fondamentaux de la première bulle internet. Hé oui, 1998~2000 : « détourner la page d’accueil vers mon portail pour y afficher de la pub ». C’est devenu en 2008~2010 : « détourner les recherches vers mon moteur pour y afficher de la pub ». Exemple qui m’a frappé récemment : afin d’effectuer un dépannage familial à distance j’installe le tout dernier MSN Messenger Live. A ma grande stupéfaction ça me change mon moteur de recherche dans mozilla ! Sans me demander mon avis, alors que, franchement, ça n’a rien à voir, utiliser un pager et mes recherches internet. C’est un peu comme si je prenais une carte orange et qu’en vertu d’accord RATP-TF1 ma télé se mettait à remplacer mes chaines favorites par TF1 et TF6 ! J’étais furieux : mon ordinateur m’appartient ! Winamp : pareil, j’installe un logiciel pour écouter de la musique et ça me propose un moteur de recherche winamp.com dans mozilla. Bref, plus ça va plus j’ai l’impression en installant un logiciel d’avoir un invité indélicat qui mets les pieds sur la table, le bordel dans mes affaires bien rangées (par exemple « Mes Documents », vas-y, fais comme chez toi), et fouille dans mes affaires… Il faudra établir une déontologie ou un label indépendant de non-malware sinon bientôt votre navigateur internet ressemblera à ça :

Non, quand une boite ayant pignon sur rue comme Microsoft fait du malware de façon aussi grossière, c’est que quelque chose va très mal quelque part.

Bref, :idea: retour aux fondamentaux.

En parlant de Microsoft, lot de consolation pour eux, en vertu de tout ce qui précède, pas besoin de se presser pour sortir son office-en-ligne-concurrent-de-google-docs… c’est pas encore le moment de tuer la poule aux œufs d’or Office…

Et pour finir, je vous souhaite une bonne année 2009 !

Partager/Sauver

Pourtant, une photo bien choisie peut illustrer la philosophie, l’idée générale derrière un concept technique, le pourquoi, alors qu’un diagramme va très vite nous emmener dans les détails et dans le comment.

 Tout ça pour dire que je m’amuse à chercher des photos pouvant illustrer les Design Patterns (ceux du GoF pour commencer ça sera déjà pas mal).

J’ai commencé par le plus évident :

 l’Adaptateur

(ou Adapter, dans la langue de shakespeare, enfin, s’il avait vécu à notre époque et avait été informaticien).

Un  peu plus subtil :

 la Façade

(ou en anglais Façade )

Je trouve que ça illustre mieux justement la fonction du pattern que le premier degré du genre de ça :

L’idée est justement de ne pas ouvrir la porte pour se balader dans toutes les pièces mais bien de piloter en ensemble de composants en boîte noire.

 Une autre illustration que j’aime tout particulièrement :

 la Stratégie 

(ou strategy, pour les plus anglophones d’entre vous).

C’est peut-être déjà un peu plus tiré par les cheveux. Et encore, c’est rien par rapport à des patterns inillustrables, comme le visiteur ou le pont (et, non, pas une photo de pont, ça serait trop simple).

En bonus, une dernière illustration, pas vraiment un pattern, mais de l’orienté objet tout de même :

  l’héritage multiple

Partager/Sauver

Finalisée également la cinquième édition de XML 1.0. Eric Van der Vlist nous explique en quoi cela augure la mort de XML 1.1 et en quoi c’est pas si grave. Les autres annonces de ce déjà fertile mois de Février, PostgreSQL 8.3, WordPress 2.3.3 (un correctif de sécurité avant tout, la mise-à-jour est fortement recommandée si comme moi comme ce site vous êtes sous WordPress) ainsi que les branches 5.5 et 6.0 de Tomcat.

Partager/Sauver

Alors, prenons le prochain ticket d’incident… voilà. bla bla bla… mmmh. OK. Ça doit pas être bien compliqué ça devrait se trouver quelque part dans cette classe, là. Tiens, je l’ai jamais ouverte celle-là. Allons-y, Ctrl+Shift+T, OK, de quoi ça a l’air ? Oh meeerde…

C’est précisément l’effet « rôh merde » qu’essaie de mesurer l’outil Crap4j, via la métrique CRAP (Change Risk Analysis and Predictions), ou bien, en français, l’ohmerditude. Cette traduction en vaut une autre, et puis j’aime bien le suffixe « -itude » .

Ce qui me plaît dans cette métrique, c’est que, pour une fois, on part de la question avant de parler de chiffres. Je n’aime pas l’approche qui consiste à constituer des tableaux de chiffres sans fin, qui certes donnent un air très savant, mais qu’on est bien en peine d’exploiter . A travers l’ohmerditude, dans le but de vérifier qu’un code est maintenable, on essaie de répondre à la question « un développeur va-t’il trouver risqué de modifier ce code lors d’une maintenance ? ». Si oui, on prend le risque que personne ne touche plus à ce code qu’entre deux doigts, le bras tendu et en se pinçant le nez de l’autre main (voir fig. 2 ). Les développeurs vont ajouter tout autour de cette boîte noire des couches et des couches de rustines et contournements de moins en moins maintenables .

Maintenant que vous touchez du doigt tout l’intérêt potentiel de cette métrique, intéressons-nous à son calcul. La formule est un dosage pifométrique de complexité cyclomatique et de couverture de tests. En gros, un code sera « crappy » (ou « ohmerdique » si vous préférez) si il est (1) très complexe et (2) très peu testé. Un code très simple sans test ou un code complexe mais très bien testé seront considérés comme acceptables.

Crap4j mélange donc le nombre de conditions à tester avec la couverture de lignes des tests… mmmmh. bon, on a vu pire. Plus exactement, Crap utilise le taux de lignes non couvertes. Si l’on pose l’hypothèse que les décisions sont uniformément réparties dans les lignes de code, alors cette mesure serait une sorte d’estimation de la quantité de décisions non testées. Malheureusement je ne connais pas d’éléments qui viendraient confirmer cette hypothèse, et ça serait quand même peu fiable.

Quel usage ?

Prise en tant que métrique isolée, cette mesure ne serait pas passionnante. Par contre, je l’utiliserais comme indicateur de testabilité et de possibilité de changement. Selon l’ISO-9126, testability et changeability sont bien des sous-caractéristiques de maintainability, on est bien en élément de réponse à la question initiale. Et comme la norme laisse complètement libre la façon de calculer des indicateurs pour les sous-caractéristiques qualité (ce qui est la façon normative de dire « démerdez-vous on vous donnera pas la formule »), Crap peut être utilisé comme formule de calcul de testabilité « sur étagère », qui présente l’avantage d’être simple à expliquer, rapide à mettre en oeuvre et déjà outillée.

A condition que vous n’ayez pas déjà d’outil de mesure qualité qui vous permette de consolider différentes mesures, et à condition également de calibrer crap4j en fonction de vos exigences, celui-ci peut constituer un premier niveau d’outillage qui vous incitera peut-être à aller plus loin.

On préférera peut-être la version produisant des rapports (via ant, à intégrer à son build continu, donc) que la version plug-in eclipse : le public visé pour cet indicateur de risque qu’un changement soit non testé me semble plutôt le gestionnaire (chef de projet par exemple) que le développeur, qui va probablement garder sous les yeux dans son IDE des règles de codage plus immédiatement « actionnables ».

Partager/Sauver

Le JavaScript généré par le compilateur GWT est incompréhensible

Je suis d’accord à 100%… mais je ne vois en quoi c’est un problème ! J’ai un aveu vous faire : j’ai fait pas mal de Java jusqu’ici, et je ne suis jamais allé lire le bytecode généré dans mon fichier .class. Honte à moi. Oserai-je l’avouer ? Je ne saurais de toute façon pas lire du bytecode. Curieusement, cela ne m’a jamais empêché d’écrire du Java…

Ça revient à dire qu’il ne faut pas faire de langage C parce-que, eh bien, le langage machine qui est produit en « -O2« , on le comprend pas… Le but du compilateur est justement de générer du code que l’on a pas envie d’écrire à partir d’un langage généralement de plus haut niveau…

Oui, mais, ah aaah ! Et si le compilateur GWT a un bug ? Il faut modifier le code généré !

Je vais même aller plus loin dans votre direction : selon la bonne vieille loi de Murphy, il y a sûrement plusieurs bugs dans le compilateur GWT. Là encore, a-t-on attendu le tout dernier gcc stable pour faire du C ? Je vous mets au défi, quel que soit le langage, de trouver un compilateur qui n’ait jamais eu un bug ! Dans ce cas-là, on triture, on contourne.

Ça serait effectivement hypocrite d’affirmer qu’il n’y a pas de souci parce-que le compilateur est open-source. Qui a vraiment envie d’investir le temps nécessaire à rentrer dans le code interne d’un compilateur ? Moi pas.

La bonne question est plutôt : quel est le risque lié à un bug dans le compilateur GWT ? Voyons voir… Détecter un comportement différent entre le JavaScript généré et le Java sera probablement mis en évidence par un test unitaire (les plus paranoïaques d’entre nous pourront générer également le javascript pour les tests unitaires et les exécuter in situ dans le navigateur). Reste plus qu’à trifouiller un peu le Java jusqu’à trouver une séquence qui compile correctement (vous voyez maintenant pourquoi je vous parlais de test unitaire ). Au pire, (r)écrivez la séquence problématique en JavaScript via JSNI. La probabilité de tomber sur un bug 100% bloquant et/ou souvent sur des bugs de compilation sévères me semble très faible et donc acceptable.

Oui, mais le JavaScript généré sera « sub-obtimal » ! Sûrement pas aussi bien que mon JavaScript finement ciselé !

Premièrement : la loi de Moore. Les navigateurs modernes sont capables d’exécuter de mieux en mieux le JavaScript. La différence supposée de performances est-elle vraiment grave ? Attention à ne pas faire d’optimisation prématurée (« la racine de tous les maux »), le javascript généré suffira-t’il à faire passer la réactivité d’un script de acceptable à non-acceptable par l’utilisateur ?

Deuxièmement, il est possible que le javascript généré par GWT sera bien plus concis :

• Le compilateur essaie de ne conserver que le code réellement appelé. Je peux me constituer une librairie de composants GWT réutilisable entre les projets, le compilo reconnaîtra les siens. Au contraire, les frameworks JavaScripts sont pour la plupart peu modulaires.
• Le code GWT n’ayant pas besoin d’être lu/maintenu, il subit une sorte d’obfuscation lors de la génération de JavaScript, il est bien plus compact que le JavaScript que vous allez écrire. Ou alors vous ne mettez jamais de commentaires et vos noms de fonctions et variables tiennent sur trois caractères . Dans ce cas je vous prierai de quitter ce site immédiatement. Je ne vous salue pas .

Oui, mais mon framework JavaScript fonctionne sur tous les navigateurs

Ça me semble au contraire la meilleures des raisons de faire du GWT : ne plus s’en occuper ! Le code généré essaie tout autant d’être multi-navigateur. A moins que le projet GWT meure, on peut supposer qu’une mise-à-jour du compilateur permettra de simplement recompiler et déployer pour que l’application soit compatible avec tout nouveau navigateur.

Alors tu rejettes en bloc toutes nos critiques ! Tu n’es pas objectif non plus !

C’est vrai, j’adore le principe de GWT

Mais l’implémentation, elle, est critiquable bien sûr. Les remarques pertinentes des javascripteurs sont :

• GWT réussit à peu près bien à encapsuler le DOM, mais échoue (pour l’instant) à encapsuler CSS correctement. Il vaut mieux connaître un minimum de HTML+CSS avant de démarrer un développement GWT : Java n’y suffit pas.
• GWT n’est pas mature. On trouve dans GWT les attributs d’une techno assez jeunes : documentation incomplète, exemples de code tenant lieu de documentation, bugs effroyables dans la librairie, les « c’est pas possible ça a jamais été testé comment ils veulent que ça marche ça ! » et les « j’ai fouillé partout je trouve trop pas la fonction pour …, c’est pas possible, ils ont jamais fait une vraie appli avec leur truc ». Bref, attendez-vous à des surprises en allant plus loin que le « bonjour, monde ». Cet effet est rattrapé en partie par la réactivité du projet, on sent d’une version à l’autre qu’il est bien piloté par les demandes de la communauté.
• GWT n’est pas à niveau côté Java. Oui, les génériques me manquent… on y prend vite goût.

Si vous voulez voir dans quelle direction va GWT, allez lire Making GWT Better.

Partager/Sauver