Tout d’abord j’ai fait 3 soirées ce soir : tout d’abord la présentation de Didier Girard sur GWT qui était vraiment sympa, la présentation de Jérome Louvel sur RESTlet et enfin la troisième mi-temps avec toute l’équipe du JUG et une dizaine de geeks autour d’une petite bière.

De l’avis de tout le monde, Didier a donné l’envie d’essayer GWT. La présentation rondement menée nous a permis de voir ce qu’est GWT. Cher lecteur ce soir je suis fainéant pour la première fois… Je ne vais pas bloguer des pages et des pages, je vous propose en attendant de relire des billets plus anciens sur GWT comme celui-ci ou celui-la sur Ext-GWT vs GWT-Ext.
Comme discuté avec Antonio, cela fait plaisir d’avoir quelqu’un qui apporte son expérience et partage sa passion sans concessions. En effet, Didier étant directeur technique de SFEIR, il parle en connaissance de cause, ce qui m’a intéressé.
Nous avons vu entre autre un plugin dans Eclipse facilitant l’écriture de code pour GWT, que GWT fonctionne avec Java 5 depuis le 28 août 2008, et un ensemble d’URL de sites d’exemples qui montrent GWT en action.
Mon avis sur la question c’est que GWT est destiné à réaliser des applications riches, et qu’en terme de productivité c’est un moteur puissant qui permet facilement de construire son application. Maintenant d’un point de vue web, je pense qu’il serait dommage de penser que GWT permet de faire une application type « vente de billet de trains »… Mais j’aimerai être convaincu du contraire.
En terme de mise en place, là où Adobe Flex propose avec BlazeDS et LiveCycle des solutions du côté du serveur, il n’y pas de solutions en GWT, car on parle bien d’un framework de présentation.
Je trouve par contre génial ce concept d’écrire du Java, de débuger dans Eclipse (ou IDEA IntelliJ) puis ensuite seulement de produire son code Javascript pour chacun des navigateurs, chacunes des langues supportées. Google est sur une niche et ce concept est réellement novateur.
Donc je reste fortement intéressé mais mon coeur balance plus pour Flex. Quitte à faire une application type client riche, je préfère travailler avec Flex. Cela me coûte une phase d’apprentissage du langage ActionScript, mais je gagne quelque chose par rapport à GWT, qui est le support de différents protocoles d’échanges entre le client et le serveur. Soit un échange de XML basique, soit du JSON, soit encore mieux, un format binaire propriétaire à Adobe qui permet d’optimiser encore plus la bande passante et les échanges entre le client et le serveur.
Merci en tout cas à Didier et vous pouvez retrouversur son site les URLs des démonstrations.

Ensuite un petit break pour le buffet organisé par la société Novedia Solutions. Honnêtement merci à eux car j’ai réussi à me caser derrière le buffet avec Cyrille Leclerc, Antonio Goncalves, Thomas et Alexis Moussine-Pouchkine. A nous 4 nous avons appliqué le pattern « Interceptor » et « Introspection » sur les plats de petits fours, que du bonheur.
Ma conclusion c’est que Spring n’a rien inventé. Au lieu de devoir faire un get et un set sur les petits fours, le serveur nous a tendu le plat et nous n’avions plus qu’à nous injecter ces bons petits gâteaux. Vive l’inversion de contrôle.

Bon reprenons la suite. Jérôme Louvel, membre de l’OSSGTP et auteur de Restlet nous a fait une démonstration plutôt pointue de Restlet. Tout d’abord ce que j’ai compris : Restlet est un framework léger REST en JAVA qui offre un système du côté client comme du côté serveur pour acceder à des Ressources. Je trouve que l’architecture REST est franchement intéressantante, et si vous voulez relire une présentation à ce sujet, voici un billet que j’aime bien écris il y a quelques mois sur REST.
Parlons un peu des choses qui fâche, désolé Jérôme si tu me lis. La présentation était vraiment très complète, voir un peu trop détaillé je pense pour le sujet de ce soir. Les efforts de migration et de portage vers la dernière version de GWT, quoique vraiment intéressant d’un point de vue technique, ont peut-être fait décrocher une partie de la salle.
Je pense qu’il est difficile en une heure de parler à la fois de Restlet et à la fois de GWT, c’était le format de la soirée qui donnait peut-être le cadre.
En tous les cas la présentation nous a donné un bon aperçu de Restlet et j’aurai aimé te poser des questions sur les annotations.
J’ai pensé un moment que Restlet se propose d’être un ‘ESB’ à la fois du côté du client et du côté du serveur, en simplifiant l’accès aux ressources et en utilisant les principes de REST. Durant la présentation, tu as cependant bien expliqué que grâce à Restlet, une application de type webmail a ajouté le support de GWT pour un coût de développement léger. Le système de sélection du type de rendu selon la source était bien expliqué.

Après la présentation nous nous sommes retrouvés au Falstaff à côté de l’ISEP autour d’une bonne bière. Moment agréable où j’ai écouté pas mal de monde, très sympa.

Sur ce, je vous donne rendez-vous la semaine prochaine pour un billet spécial pour fêter l’anniversaire du Touilleur Express ainsi que des nouveautés autour de Spring dès jeudi 13 novembre après la journée « Les Rencontres Spring« .

Je vous en reparlerai cette semaine.

La semaine dernière, à l’occasion de la journée Client Riche organisée par Valtech, je vous ai reparlé un petit peu de Google Web Toolkit. En quelques mots, GWT permet d’écrire en Java du code qui sera transformé en Javascript pour fonctionner du côté du navigateur du client. L’intérêt de GWT est son mode hébergé. Lorsque vous développez, ce qui est bluffant c’est la rapidité à laquelle vous pouvez construire votre interface. En effet, nul besoin de compiler quoique ce soit. Vous éditez simplement votre code Java, vous sauvez votre fichier, un rechargement dans l’outil GWT et votre modification apparaît immédiatement dans un navigateur utilisant la DLL d’internet explorer.

GWT ne dispose pas d’une librairie de composants très riche. Il existe dans le monde Javascript des librairies très puissantes. La librairie Ext-JS est l’une de mes favorites. Le problème de cette librairie est qu’il faut une bonne maitrise du langage Javascript et pas mal d’énergie pour développer une interface complète. Croyez-moi, je sais de quoi je parle.

Pour rejoindre le meilleur de ces 2 mondes, Sanji Jivan a développé GWT-Ext, une librairie qui se repose sur GWT, Ext-JS 2.0.2 ainsi que quelques composants supplémentaires comme les courbes en 2D (YUI) et le module Pagebus destiné à s’interfacer avec Tibco. Cette librairie est distribuée sous licence LGPL v3.
Je vous conseille de regarder la page d’exemple pour vous faire une idée de ce qu’il est possible d’écrire en Java, et qui se transformera en Javascript au final pour le client.

Le souci et le débat est que Jack Soclum, qui travaille sur la librairie Ext-JS a effectué un changement de licence en avril dernier. La librairie Javascript est passée d’une licence LGPL à une licence GPL v3. La conséquence pour les logiciels développés sur cette librairie, est qu’ils doivent soit adopter une licence virale comme la GPL, soit acheter une licence commerciale à l’entreprise de Jack. Cela a provoqué pas mal de remous dans la communauté des utilisateurs de la librairie Ext-JS. A priori les choses sont entrain de changer et on parle de mettre en place des exceptions pour les produits open-source quant à l’utilisation de la librairie Ext-JS. Voir ce post sur Ajaxian. En tout les cas Jack Solum s’est fait largement critiquer pour le passage d’une licence LGPL à une licence GPLv3, comme il l’explique sur son blog (note: il y a un post de Ludovic Dubost, OSSGTP, XWiki dans les comments). Quelque part c’est très informatif sur le côté épidermique des licences et de ce que les gens en font… On entre dans le débat LGPL/GPL…

Toujours est-il que le problème pour GWT-Ext est que ce projet reste à la version 2.0.2 de la librairie Ext-JS et ne pourra pas passer à la version 2.1 d’Ext-JS distribué en GPL. Dans le même temps, le groupe Ext-JS a lancé sa propre version du portage vers GWT de la librairie Ext-JS (honnêtement si vous suivez et vous êtes encore entrain de me lire, chapeau…). Actuellement la couverture fonctionnelle n’est pas encore très complete. Voici les deux liens pour comparer la première librairie (GWT-Ext) et donc la deuxième que j’appelle GXT mais dont le nom officiel est Ext-GWT… Comment embrouiller le développeur lambda…

• Démo GWT-Ext http://www.gwt-ext.com/demo/
• Démo Ext-GWT dit « GXT » http://extjs.com/products/gxt/

Je travaille sur un projet pour le mois de septembre pour lequel, après avoir fait un prototype avec JBoss Seam et IceFaces, j’ai eu envie de tester un rendu basé sur GWT. J’ai donc développé 2 prototypes avec chacune de ces librairies (GWT-Ext et GXT) afin de me faire une idée précise des lacunes et des points forts de chacune d’elle.

La librairie GWT-Ext est sortie en juillet 2007. La documentation est assez complète et la prise en main assez rapide. Complètement basée sur Ext-JS, on retrouve donc la manière de programmer cette librairie. Simplement, le fait de travailler en Java me permet de travailler plus rapidement qu’en pur Javascript. De plus, Sanji le développeur derrière cette librairie a intégré aussi des composants de Charts (de YUI) ce qui m’évite d’utiliser une librairie propriétaire.

La librairie GXT est encore en phase de béta. La documentation et les exemples sont moins fournis. Elle apporte un modèle léger événementielle qui fait que le code écrit me semble plus clair. La javadoc est plus complète, et lors des phases de debug, une partie de cette librairie étant écrit en Java, il est plus facile de travailler qu’avec GWT-Ext.

GWT-Ext est un wrapper complet qui utilise JSNI pour effectuer des appels Javascripts vers la librairie Ext-JS directement. Au contraire, GXT dispose de sa propre implémentation en Java. Au final c’est bien du javascript qui est généré.

Le post suivant de Didier Girard propose un petit tableau pour comparer les 2 librairies.
http://www.ongwt.com/post/2008/04/22/MyGWT-is-dead-Long-live-Ext-GWT

Au final je vais m’arrêter là… J’ai un prototype développé avec les 2 librairies. Je me suis cassé la tête sur GWT-Ext en particulier lors de la mise en place de la partie dynamique. Ext-GWT par contre me permet d’écrire du code avec une architecture plus propre. Donc c’est fait.

Fin du débat

L’organisation de Valtech était à la hauteur de l’événement. Environ 90 personnes étaient présentes. En majorité des développeurs Java. Il y avait quelques développeurs .NET, PHP et des graphistes. Mais le premier constat, c’est que soit le fichier de prospection de Valtech n’a contacté que des équipes Java, soit clairement un développeur client riche en France n’est pas un graphiste mais un développeur…

Nous étions environ une cinquantaine dans mon groupe. Tout le monde était équipé d’un portable avec les différents environnements de développement installés grâce à un CD donné par Valtech. La première session sur Google Web Toolkit était animé par Sami Jaber de DNG Consulting, ancien directeur technique chez Valtech Toulouse. Sami a été interviewé plusieurs fois dans 01 Informatique (ici, là sur JavaFX et ici sur RDA). Son blog parle aussi de .NET. Je retiens plusieurs points sur sa présentation. Tout d’abord il explique que GWT n’est pas réellement comparable à SilverLight ou Flex. Il n’y a pas de plugin et pas de rendu vectoriel. GWT est orienté application web riche. L’avantage de GWT est son intégration complète dans l’espace de travail du développeur. Le développeur écrit en Java une application similaire à de la programmation ave Swing pour décrire votre interface et vos actions. Ce code génère du Javascript avec l’outil GWT qui est ensuite déployé vers le client. L’un des points forts de GWT est la génération optimisée du Javascript selon le navigateur ainsi que selon la langue de l’utilisateur. GWT prend en charge la complexité de gestion des différents navigateurs et permet donc de ne se concentrer que sur la partie métier. A peu de chose prêt c’est ce que nous faisons avec mon équipe sur le framework Karma depuis 3 ans, pour la finance. Là où par contre GWT va plus loin, c’est son intégration dans l’environnement de travail. Chez nous la productivité n’est pas mirobolante car la phase de debug est assez délicate. Sur GWT la productivité est bien meilleure que notre solution.

GWT seul est pauvre en terme de composants graphiques. Cependant il faut savoir qu’un bon nombre des librairies Javascript sont en court de portage vers GWT. Sami a présenté une intégration de la librairie ExtJS dans le projet Ext GWT (ou GXT) qui m’a particulièrement intéressé. ExtJS est une librairie très puissante mais difficile à programmer proprement, car c’est du Javascript. Il existe bien une taglib pour ExtJS mais je ne suis pas convaincu. Ext GWT par contre est vraiment une librairie qui a un avenir au sens industriel du terme. Je vois déjà les applications chez Thomson-Reuters qui pourraient en bénéficier pour pas très cher. La librairie est disponible soit sous licence GPL v3, soit sous licence commerciale si vous souhaitez l’intégrer dans un produit. C’est la mode en ce moment.

GWT est donc une librairie et un moteur complet qui permet de travailler d’Eclipse (ou d’IDEA IntelliJ) rapidement, sans devoir déployer son application et perdre du temps. L’exemple de Sami utilisait Apache OpenEJB, un tout petit moteur EJB3 qui a l’avantage de se lancer très vite par rapport à un JBoss. Je ne parle même pas d’IBM Websphere et compagnie…

Deuxième séance: Microsoft Silvertlight beta 2 release 2. Je ne vais pas m’étendre. Très décevant. La présentation était moyenne, les 2 présentateurs ont proposé d’axer la présentation sur l’intégration entre l’utilisation de Microsoft Blend et d’un outil de développement C#/XAML afin d’expliquer la séparation entre le design graphique et la partie codage. Mon sentiment sur ce que j’ai vu, c’est que Silverlight n’est pas encore terminé. Certes on parle d’une béta. Mais en fin de présentation, l’un des speakers a expliqué que dès aujourd’hui il était possible d’aller en production avec un support qui sera assuré par Microsoft… Moi désolé mais je n’ai rien compris.

J’ai apprecié Microsoft Blend qui est un outil puissant pour construire son interface. Il écrase Flex Builder car il permet vraiment d’aller très loin sur les effets graphiques et de présentation. En terme d’ergonomie, je trouve qu’il y a encore quelques points à clarifier, mais l’outil est utilisable pour faire une interface très sympa. Du côté de XAML et du pont avec la partie métier et service, une application cliente Silverlight est agnostique avec la partie serveur. Elle peut donc être client d’un Tomcat sans soucis. Silverlight supporte un grand nombre de modèle de communication comme REST ou RPC. Il y a une couche de sécurité que je n’ai pas vu du côté de Flex. Anecdote cependant qu’un des présentateurs a laché : le contenu XAP d’un fichier silverlight est placé dans le cache du navigateur. Il serait possible de récuperer ce contenu pour le décompiler et en faire ce que l’on veut. Il explique donc qu’il faut faire attention à ne pas stocker de choses sensibles dans l’application, mais à aller les chercher sur le serveur. Ce qui me paraît logique.

Quoi d’autre sur Silverlight ? je vous passe les manipulations assez acrobatiques que nous avons dû faire car il y a un souci de Namespace sur la dernière version de Blend. C’était folklorique. Moi en tant que client j’attendrai encore un peu avant de m’en servir pour un client final. Je n’ai pas du tout aimé la partie C#. Cela dit, Silverlight a aussi un support pour PHP et Ruby. Donc on peut envisager d’écrire autrement la partie Page de l’application. Voili voilà.

Nous avons terminé la journée par la présentation qui m’a le plus bluffé : Adobe Flex. Je connais bien la techno puisque l’an passé j’ai réalisé tout un prototype avec Flex de l’une de nos applications. Je voulais rester afin de voir comment présenter Flex aux gens qui ne connaissent pas. Yann Chevalier de Baao nous a fait une superbe présentation. C’est un très bon speaker et je pense que toute la salle a réussi à réaliser les ateliers qu’il présentait. Nous avons codé un player de vidéo en Flex, avec une timeline, des boutons Pause et Stop et un compteur de temps. Cela permet de voir comment utiliser le Designer pour créer l’interface. Ensuite comment binder un composant à un événement. Comment déclarer un composant réutilisable… Bref une très bonne présentation. Rien à dire, je reste convaincu que pour l’instant Flex a une bonne longueur d’avance sur Silverlight. Flex est pensé par des graphistes, des ergonomes, des développeurs Flash qui ont une grande expérience du Web là où Silverlight est orienté développeur. Cependant j’ai vu qu’en terme de rendu, Silverlight est plus puissant dans ses effets graphiques. Là où pour l’instant cela pêche un peu, c’est que des applications avec de la vidéo et des cubes qui tournent, il y a peu d’intérêt à en faire… Nous sommes encore en phase de transition vers du Web un peu plus riche, ce que GWT qui reste sur du HTML et du JS fait très bien.

En conclusion, je suis reparti avec un tee-shirt GWT. C’est pas marrant à dire mais les teeshirts Silverlight sont restés sur les tables de la salle d’accueil. Problème de publique je pense. Les gens présents étaient en majorité des pro-Java et malheureusement le fossé continue à se creuser. J’en suis responsalbe aussi en faisant du bashing ici. Mais je ne vais pas pipoter en racontant que c’est une techno mature et prête à être mise en production chez un client, un trader, dans une salle de marché… C’est une bonne techno mais avec un concurrent comme Adobe Flex et un produit comme Thermo qui devrait bientôt arriver, la concurrence va être rude pour Silverlight. A noter en juillet nous devrions avoir une présentation sur Flex par l’équipe d’Adobe France aux Paris Java User Group (Paris JUG).

Dans un premier temps, présentation de Flex par Yann Chevalier, puis de Microsoft Silverlight par Angelo Pacifio et enfine Google Web Toolkit par Sami Jaber.

Comme d’habitude je posterai ici un compte-rendu de cette journée afin de vous faire partager mon expérience.