• Ses origines
• Les outils et frameworks de son écosystème
• Les difficultés et freins à son adoption
• Les nouveautés de la toute nouvelle version 2.9.0
• Les entreprises qui l’utilisent
• Une session d’une heure de live coding : exemples de programmation fonctionnelle, un S-99 et… du Play Framework !

Les inscriptions se passent par ici. Venez nombreux !

Comment choisir ces fameux Frameworks Web qui sont, et c’est le moins que l’on puisse dire, assez nombreux. Et bien tout d’abord, il va falloir restreindre cette liste à quelques Frameworks et, pour chacun d’entre eux, prototyper une application. A partir de ces prototypes, il sera alors possible de créer une matrice comprenant différents critères qui seront notés pour chaque Frameworks. De là, on pourra faire ressortir les meilleurs prétendants, un petit document et faire nos recommandations. C’est ce qu’a fait Matt Raible durant cette présentation et voici ses résultats !

Matt fait un petit rappel sur les facteurs clés qui nous permettaient de choisir un Framework Web en 2007 (de son expérience) :

• composant, requête ou RIA,
• facilité de développement,
• communauté autour du Framework,
• roadmap et futur du Framework,
• maintenance,
• fonctionnalités.

Aujourd’hui, nous en demandons beaucoup plus à nos Frameworks Web et, pour Matt, nous passons de 6 à 20 ! Avec un peu d’exagération sur cette fulgurante croissance car certains points faisaient déjà parti de nos préoccupations en 2007 ; de là à dire que ce sont de nouveaux points… En tout cas, les voici au complet :

• productivité du développeur,
• perception du développeur,
• courbe d’apprentissage,
• santé du Framework,
• disponibilité des développeurs (sur le marché),
• offres d’emploi,
• templating,
• composants,
• ajax,
• plugins ou add-ons,
• scalabilité,
• support pour les tests,
• i18n et l10n,
• validation,
• support du multi-langage (groovy, scala…),
• qualité de la documentation / tutoriaux,
• publications,
• support de REST,
• support mobile,
• et degré de risque.

Bien sûr, nous pouvons remettre en cause certains points de cette liste et passer plusieurs journées à en débattre mais le débat n’est pas là. Matt assume que les choix qui sont fait sont les siens et il nous invite à participer pour ajouter des éléments à la liste ou lui indiquer pourquoi il se trompe sur telle ou telle appréciation. L’idée est ici de donner une base solide afin de pouvoir comparer sur plusieurs points importants de nos projets d’entreprise ces fameux innombrables Frameworks Web.

Roulement de tambour… voici la matrice ! (google spreadsheet)

Les gagnants de ce « concours » sont :

• Spring MVC,
• GWT,
• Ruby on Rails (non JVM mais non exclu car très présent sur le marché),
• Grails,
• Wicket.

Vient ensuite une partie avantages / inconvénients pour chacun d’eux. Cette partie est à prendre avec des pincettes car les inconvénients relevés sont souvent surmontables (certains sont même juste des comportements par défaut modifiable par configuration !) mais encore une fois cela donne un overview de ce que font ou ne font pas ces Frameworks :

• Spring MVC : configuration simple par conventions et annotations, intégration de plusieurs formats d’affichage (JSP, JSTL, FreeMarker, JSON, PDF…) et excellent support de REST mais pas de rechargement à chaud par défaut (toutefois possible avec JRebel ou Spring Roo), projet non ouvert à la communauté pour contribution (SpringSource mandatory) et pas de librairie ajax en bundle (ce qui peut aussi être vu comme un point positif car mise à jour des librairies Javascript non bloquée par le Framework) ;
• GWT : code Java traduit en un Javascript extrêmement optimisé, apprentissage facile et rapide (petit bémol car sur ce point les développeurs Web n’ont pas forcément cette compétence du code Swing-like) et une communauté vibrante mais il faut connaître Java (alors que l’on produit du Javascript), compilation très lente et code difficile à tester ;
• Ruby on Rails : apprentissage rapide pour tout développeur Web, documentation abondante et communauté de passionnés mais moins performant que les autres langages, langage dynamique = plus de tests pour éviter les cast exceptions au runtime et un manque d’outils de développement et de débugger comme dans le monde Java ;
• Grails : transition facile depuis le monde Java, utlise Groovy et nombreux plugins mais Groovy vise directement les développeurs Java (ce qui peut bloquer d’autres développeurs), stack traces affreuses (dans le slide ) et connaissances des sous-modules non nécessaires mais peut aider ;
• Wicket : parfait pour les développeurs Java, binding des pages et des vues et communauté active mais pas ou peu d’offres d’emploi, stateful par défaut et templates HTML juste à côté des classes Java (ce qui ne va pas aider le graphiste).

Pour finir, nous avons droit à quelques jolis graphiques qui nous montre à quelle point Ruby On Rails est très présent au niveau de la communauté mais ainsi en terme d’offres d’emploi.

Matt a insisté sur deux points importants tout d’abord sur le fait que ce sont les développeurs qui devraient choisir leur framework web, plus les développeurs sont heureux, plus ils seront productifs. D’autre part, javascript n’est pas si difficile comme on l’entend souvent de la part des développeurs java, plus on le pratique, plus on l’apprécie, et c’est vital si l’on veut être sérieux pour le développement d’application web.

Cette méthode peut être appliqué dans votre entreprise pour choisir votre framework web :

1. priorisez les fonctionnalités importantes de votre application
2. sélectionnez ensuite 3 ou 4 Frameworks pour prototyper une application (1 semaine chacun), documentez
3. calculez votre matrice et choisissez !

C’est parti pour le show : les puzzlers en photo, et les remarques et solutions en commentaire !

Puzzler n°1

BigDecimal permet un calcul de précision que l’on ne peut avoir avec des doubles donc vous pensez tout de suite à a) ou b). En même temps, ça sent le piège car nos doubles sont toujours utilisés directement donc plutôt la c). Et bien vous avez tout faux, réponse d) !

En effet, le code passe par le constructeur public BigDecimal(double val) qui va donc représenter la valeur décimale exacte (jusque là tout va bien) d’un double à virgule flottante… donc incorrect. Et comme nous sommes en présence d’un double, nous avons la réponse d), la réponse c) étant la représentation pour un float. La solution est de passer par un String et d’utiliser ainsi le constructeur public BigDecimal(String val).

Puzzler n°2

La bonne réponse est la réponse a). La solution de ce Puzzler mériterait un article complet car beaucoup de paramètres entrent en jeux. Et ça tombe bien puisque cet article existe ! Je vous laisse donc apprécier le détail chez Alex Miller pour ce Puzzler qui s’amuse avec la méthode entrySet() d’EnumMap (même comportement pour IdentityHashMap, ConcurrentHashMap a été corrigé) et le constructeur addAll() du HashSet.

Puzzler n°3

Les solutions possibles pour ce Puzzler sont : a) 99 b) 100 c) Throws an exception d) None of above.

Et la réponse est d) avec un calcul qui va tourner très longtemps

Nous sommes face à un catastrophic backtracking qui génère un calcul exponentiel pour trouver le résultat !

La solution ? Retirer le ?. Cette nouvelle RegExp (aa|aab) fonctionne exactement comme (aa|aab?) mais sans exposer ce catastrophic backtracking. Ce Puzzler n’est donc pas un bug Java mais une manière de mal écrire une RegExp.

Willian Pugh nous confirme donc que nous aurons le même problème en Ruby, Python, Perl… Joshua Bloch se demande alors Even in Scala ? Réponse de son partenaire : Yes, even in Scala ! Ce qui a bien fait rire la salle

Puzzler n°4

Les solutions possibles pour ce Puzzler sont : a) ["null", null] b) [null] c) [null, null] d) None of above.

La solution est la réponse d) avec une superbe ClassCastException qui sort de nulle part ! Et bien, pas vraiment de nulle part quand on regarde de plus près. L’exception est levée dans la classe StringSink, mais il est difficile de voir quelle partie du code a pu générer une exception. En fait, ce sera même très difficile à diagnostiquer car le code qui provoque l’exception n’est pas visible ! Par contre, une fois la classe décompilée, on voit apparaître ce code non visible sous la forme d’une bridge method :

Utiliser un Generic T dans une méthode qui prend un Varargs (donc un tableau de T) a causé la création de cette méthode void add(Object a) qui retourne notre objet casté en String. En effet, le compilateur ne connaissant pas le type T (erasure mon amie…) et devant aussi gérer ce tableau, il est obligé de créer une méthode avec Object. A noter que le compilateur nous a prévenu dans les logs de compilation. Donc comme le rappelle Joshua Bloch : « Don’t ignore warnings ! ».

Puzzler n°5

Ce Puzzler est définitivement mon préféré :

Et une fois de plus, on se retrouve face à une exception, toujours de type ClassCastException. Encore un problème de Generics ? Oui… Car la classe Glommer() a été instanciée sans préciser le type T. Donc la classe passe en Raw type. Et ce qui se passe dans le cas présent, c’est que toutes les informations de Generics… sont supprimées de la classe !
Ainsi, les méthodes glom qui prenaient une Collection<?> et une List<Integer> se retrouvent désormais à recevoir une Collection et une List non typée. Comme la liste de String est instanciée avec Arrays.asList("a","b","c") qui retourne une List, la priorité va à la méthode qui prend en paramètre une List. Et devinez quoi : c’est la méthode qui initialement devait s’occuper des Integer ! D’où le ClassCastException dès la première valeur lors de la boucle (qui essaie de caster un String en int).
Dans ce cas, la solution est d’enlever ce type T de la classe (non utilisé dans le corps). La recommandation liée à ce Puzzler : n’utilisez pas les Raw Types et, une fois de plus, n’ignorez pas les warnings de compilation (car il y en aurait eu un) !

Puzzler n°6

Autant le deuxième est trouvable, autant pour le premier, tout le monde dans la salle est tombé dans le panneau (certains ont même crié « voleur, c’est pas un Puzzler ça ! »). La bonne réponse est la réponse b) avec 17777 et 43878.

Le premier calcul et le sujet du vol : ce n’est pas écrit 12345+54321 mais 12345+5432l.
Vous ne voyez toujours pas ? Je vous aide : 12345+5432L ! Et là évidemment cela change tout ! Nous n’avons donc plus 54321 mais 5432 (5432L en long) qui donne bien 17777.

Le deuxième calcul : 01234+43210 correspond en fait à 668+43210 ! Que s’est-il encore passé sous nos yeux… et bien le premier 0 de 01234 convertit notre 1234 en base 8 ! Ce qui nous donne 668 et donne une somme de 43878.

La morale de ce Puzzler : mettez des majuscules à vos long (5432L est un long et cela se voit) et ne préfixez jamais vos entiers avec un 0 à moins que vous ne vouliez vraiment le convertir en base 8.

Si ces Puzzlers vous ont plu, un seul livre : Java Puzzlers ! Un grand merci à Joshua Bloch et William Pugh pour cette excellente présentation !

La couverture est large : Hibernate Core, Search, Envers, Validator et Spatial. De nombreuses démos nous ont permis de nous familiariser avec ces nouveautés liées à JPA 2.
La session était animée, comme il se doit, par Emmanuel Bernard. Le code de la session est disponible sur GitHub et ce pour encore une petite semaine.

Hibernate Core – ORM

Après quelques nouveautés, dont le support de l’annotation @MapsId de JPA 2, le partial generator (pour générer une clé selon un algorithme spécifique) et le runtime fetch profile (qui définit plusieurs stratégies de fetch), Emmanuel commence sa première démo et nous présente la nouvelle API Criteria :

• query building API orientée objet,
• type-safe,
• fortement typé,
• avec la possibilité d’utiliser le méta-modèle statique (par annotation processor).

Et c’est sur ce dernier point qu’il insistera pendant toutes ses démos. En effet l’API est construite de telle manière que nous récupérerons des erreurs compile-time si un mauvais méta-modèle ou un mauvais attribut de méta-modèle est défini.

Concrètement, le méta-modèle est généré par annotation processor. Une fois celui-ci activé dans votre IDE, chaque compilation de fichier lancera le processus de génération des méta-modèles. Par exemple, une classe User aura un méta-modèle associé User_ qui contiendra plusieurs attributs statiques reflétant les attributs de la classe. Ainsi, si un attribut change de nom, toutes les requêtes utilisant l’ancien nom seront en compilation error. Voici un exemple à partir d’une capture d’un bout de code lors de cette démo :

On remarque ainsi dans les contraintes l’utilisation de User_.credits, credits étant un attribut de la classe User. On voit dès lors l’intérêt d’un tel mécanisme qui justifie ainsi son appellation type-safe et fortement typé. En effet, sur le 3ème exemple, imaginons que l’on donne un argument autre que User_.gender mais du même type que gender ; l’API nous donnera tout de même une erreur de compilation car ce qui est attendu est un Path<Gender> qui ne peut être obtenu qu’en ayant pris en paramètre un gender. Une fonctionnalité plutôt intéressante donc mais qu’il convient mieux de voir de ses propres yeux dans un IDE pour bien comprendre la puissance de la chose.

Cette nouvelle API criteria prend en compte toutes sortes de Joins et Where, les Subquery et les Map et Like. Cette API supporte ainsi tout le JP-QL : collections, maps, aggregation, order by, group by, having count, subselect, …

Le lock mode, qui prévient entre autres des dirty reads,  supporte l’optimistic et le pessimistic read/write. Le cache de second niveau a été amélioré et Hibernate supporte aussi Infinispan. Enfin, CGLIB se retrouve déprécié et se voit remplacé par Javassist.

Côté packaging, Hibernate passe de plusieurs modules à un seul core module qui contient Hibernate Annotations, Entitymanager, Envers et l’ancien Core. De même, tous les modules auront le même numéro de version simplifiant ainsi la gestion des dépendances entre modules (si un module est en 3.6.0, les autres devront l’être aussi).

Hibernate Search

Le point important est une fois de plus l’API programmatique permettant de faire ses requêtes full text directement telles que :

Dans les petits plus : un error handling pour reporter dans un log ou dans une pile, des statistiques avancées, une indexation des valeurs null, des query timeout et bien d’autres.

Hibernate Spatial

Hibernate Spatial est une extension d’Hibernate permettant de gérer des données géographiques. Il s’appuie sur le package Java Topology Suite ou JTS pour représenter les données géographiques dans le monde Java.

Voici ce que rajoute le projet à Hibernate :

• GeometryUserType.
• SpatialRestrictions API.
• HQL Spatial functions.
• SpatialDialectProvider.

Les bases de données supportées sont les suivantes :

• Oracle Spatial.
• Postgresql/Postgis.
• MySQL.
• Microsoft SQL Server 2008.
• H2 (GeoDB).
• IBM Informatix IDS (en cours).
• IBM DB2 (à planifier).

Les spatial queries s’écrivent comme des requêtes criteria normales mais dans le monde spatial. Un exemple tiré du slide :

A noter que pour l’instant le projet est un module à part d’Hibernate 3 mais qu’il sera packagé dans Hibernate Core en version 4.

Hibernate Envers

Comme pour les autres modules, l’API programmatique est tout de suite mise en avant avec des requêtes Criteria par révision sur les objets :

Hibernate Validator

Là encore, l’API a aussi été remaniée et l’on peut ainsi appeler directement des méthodes du type .constraint(SizeDef.class).min(1) dans notre requête Criteria (équivalent de l’annotation @Min).

Conclusion

Un bon tour d’horizon des produits Hibernate mais surtout beaucoup de démos les mains dedans où l’on voit le tout fonctionner en @Inject et Weld sous IntelliJ IDEA. Une bonne session !

Accélération

Taper au clavier est bien plus rapide que la navigation avec la souris. On perd beaucoup de temps à chercher alors que les raccourcis clavier sont bien plus rapides. Chaque OS fournit ses raccourcis claviers pour ouvrir l’explorateur Windows ou le Finder. Pour naviguer sur internet, utilisez NumberFox, il numérote les liens sur les pages et permet en saisissant un numéro d’accéder à la page associée. Pour la gestion du presse papier, utilisez par exemple jumpcut sur MacOS X qui permet de visualiser ce que vous avez coupé ou copié avec un historique des données. Le changement de contexte prend du temps également, surtout en ligne de commande. Avec les commandes pushd/popd, vous pourrez mémoriser un répertoire avec pushd pour le réutiliser ensuite à tout moment avec popd.
Lignes de commande ou explorateur ? Les explorateurs sont intéressants dans certains cas, les lignes de commandes dans d’autres. Pour switcher facilement de l’un à l’autre, vous pouvez utiliser cmd prompt explorer bar pour Windows et Path Finder pour Mac OS X. Ils proposent dans une même fenêtre la console et l’explorateur.
Quand vous codez, vous devriez toujours utiliser le clavier plutôt que la souris. Forcez vous à apprendre les raccourcis clavier. Un outil existe sur IntelliJ pour forcer les développeurs à utiliser un raccourci clavier, au bout de la troisième utilisation la fonctionnalité se grise dans le menu. Les conseils : se les répéter et se créer un aide mémoire. Accédez directement à la classe que vous cherchez par les raccourcis clavier et en utilisant les majuscules. Prenez l’habitude de créer les variables avec votre EDI. Bien que destiné au refactoring, vous pouvez aussi l’utiliser en ne déclarant que la partie gauche de la déclaration et générer le reste.

Focus

Pour commencer, il y a des choses simples à mettre en place : une chaise confortable, un double écran, les droits admin sur son poste et un bon clavier. Ensuite la concentration doit être total. Pour être productif, il faut supprimer toutes distractions tels que les pop-ups Windows de mis à jour ou autres notifications. Il existe par exemple Jedi Concentrate qui permet de mettre en noir toutes les fenêtres pour se concentrer sur une en particulier le plus longtemps possible. Désactivez toutes les notifications d’emails et de messageries instantanées, mettez des écouteurs et créez des « moments de silence » dans votre bureau.
L’idée n’est pas de s’isoler des autres mais de créer des conditions idéales à la concentration.

Focus technique

Utilisez un outil de recherche tel que Google Desktop Search pour rechercher sur votre poste au lieu de naviguer dans votre explorateur. Utilisez un virtual desktop pour séparer votre espace de travail du reste. Cela permet d’éviter l’empilement de fenêtres sur un unique bureau.

Canonicité

Faire les choses simples en évitant les répétitions. Neal Ford a un sigle de référence : DRY (Don’t Repeat Yourself).

• DRY o/r mapping : il s’agit d’une tâche assez répétitive dans le développement d’application. Optimisez la partie mapping avec la base de données en construisant celui-ci à partir des méta-données en base. Puis générez les POJOs correspondant.
• DRY documentation : Neal Ford a utilisé SVN2Wiki un petit utilitaire de SVN qui relève tous les commentaires de commits des développeurs pour les aggréger dans un wiki.

Automatisation

Les aspects visiblement automatisables sont le build en une commande, l’intégration continue, le contrôle de version et la documentation. Il recommande Selenium pour les tests automatisés. Ce dernier permet au développeurs de tester plus rapidement les applications suite à une modification.
Sa philosophie est : « Ne perdez plus de temps à faire à la main ce que vous pouvez faire automatiquement ».
Pour déterminer si une tâche est automatisable ou pas, il faut mesurer le temps qu’elle prend et analyser le retour sur investissement. Il faut éviter également d’en faire trop.

Pratique

Neal Ford nous propose ensuite 10 bonnes pratiques pour améliorer notre productivité et notre qualité de code.

1. Pattern Composed Methods

Celui-ci est directement tiré du livre Smalltalk Best Practice Patterns de Kent Beck. L’idée est de diviser son programme en plusieurs méthodes, chacune ayant un et un seul rôle bien défini. De même, chaque opération dans la méthode devra avoir le même niveau d’abstraction. Le résultat : des méthodes avec un rôle précis écrites en très peu de lignes de code. Cela a pour avantage de favoriser et simplifier les tests unitaires. Cela permettra aussi de vraiment mettre en avant la vraie réutilisabilité du code.

2. TDD

Couplé avec le pattern Composed Methods, TDD nous oblige à réfléchir à notre design objet, à définir de quels objets dépend mon objet et ainsi à mocker ces objets dépendants. Un premier constat est que l’on obtient très souvent de meilleurs métriques de manière globale.

3. Analyse de code

Les outils d’analyse de code, ce n’est pas quelque chose de nouveau. Mais un petit rappel ne fait jamais de mal Passer par ce type d’outils va nous permettre de détecter des bugs de type mauvaise pratique, code mort ou bien encore du code violemment copier-coller. 2 types d’analyse :

• byte code : à l’aide de FindBugs qui nous range nos bugs par catégorie comme la mauvaise pratique, le problème de performance ou du code douteux ;
• source code : par PMD qui lui nous détectera le code mort ou bien encore le fameux algorithme CPD pour Copy/Paste Detector.

4. Bonne citoyenneté

Avec une formule : getters + setters != encapsulation ! Le speaker insiste alors : ne générez pas automatiquement sans réfléchir ces fameux getters et setters. Et si vous en avez réellement besoin, il faudra peut-être les tester.
Et un exemple d’API worst citizenship in the java world selon lui : java.util.Calendar ! Et un exemple très saisissant : que donne une instance de Calendar avec 31 février ? Et bien une instance de Calendar au 1er mars ! Alors que l’on ne serait pas surprit de se prendre une petite exception à la figure… Avec un constructeur sans paramètre, un autre avec tout, encore un autre avec seulement la moitié des paramètres demandés… En bref : prenez JodaTime

5. YAGNI

L’idée est simple : si vous n’en avez pas besoin tout de suite, pourquoi le faire ? Et oui, You Ain’t Gonna Need It !

6. Remettre en cause l’autorité

J’ai beaucoup aimé l’exemple cité : le nom des méthodes en Java. La norme est en effet d’utiliser le CamelCase pour le nom de nos méthodes. Mais prenons par exemple les test unitaires et par exemple ce test :
testUserCannotAccessThisPageWithHisActualGrantedAuthorities
Pourquoi, pour une question de lisibilité, ne pas le nommer :
test_user_cannot_access_this_page_with_his_actual_granted_authorities
Le nom de la méthode devient alors plus lisible et on obtient plus facilement l’information de ce que fait le test.
Autre cas : le chainage de méthode. Là où l’on écrirait des appels successifs de méthodes setXXX avec un retour de type void, pourquoi ne pas revoir l’API et utiliser le Chaining Pattern pour avoir quelque chose du type : Car.describedAs().box().length(12).includes(Equipment.LADDER);. Neal Ford insiste sur cet exemple car celui-ci remet directement en cause la spécification Java Beans.
Il ne faut donc pas forcément s’arrêter sur des phrases telle que c’est comme ça qu’il faut faire, un point c’est tout !

7. Slap

Slap pour Single Level of Abstraction Principle, ce principe rejoint fortement le Composed Pattern puisque le concept est d’avoir plusieurs lignes de code dans une méthode ayant le même niveau d’abstraction.

8. Polyglotte

Java n’est pas le seul et, pour certaines problématiques ou certains environnements, il est peut-être préférable de partir sur d’autres langages. Exemple : JRuby pour faire de l’interface graphique ou Jaskell pour écrire du code fonctionnelle. En bref, ne pas se limiter à Java.

9. Chaque Nuance

Java traîne avec lui des idées reçues bien fausse comme par exemple que l’API reflection est lente, certes vrai en fin des années 90 mais plus aujourd’hui. Il faut donc nuancer les propos, ne garder que ce qui est vrai et ne pas hésiter à faire passer le message pour que toutes ces choses ne soit plus dites !

10. Anti-objets

Neal Ford nous explique qu’un anti-objet peut-être vu comme un objet qui fait exactement l’opposé de ce pourquoi il a été créé. L’exemple du vase ou visage nous permet ainsi de voir qu’un objet vase peut voir sa réelle existence complètement détournée.

Conclusion

Une session extrêmement riche et un livre à lire de toute urgence !

NB : Les slides de Neal Ford sont disponibles sur son site : Devoxx 2010 – Neal Ford – The Productive Programmer.

Mylyn, c’est le framework ALM (Application Lifecycle Management) d’Eclipse. Il réorganise tout l’IDE autour de tâches. Celles-ci seront ensuite traduites par Mylyn pour nos différents outils comme notre gestionnaire de sources, notre intégration continue ou bien encore notre bugtracker. Le développeur pourra ainsi ne se préoccuper que de ses tâches, Mylyn s’occupant du reste.

Oliver Gierke nous oriente vers 3 grands domaines concernant cette fameuse productivité recherchée du développeur : focus, productivity et traceability.

Focus

Tout se passe dans l’onglet Task List d’Eclipse avec une liste de tâches à effectuer. A noter qu’on ne peut activer qu’une seule tâche à la fois.

Le concept : chaque tâche aura son propre contexte de travail.

Ainsi, dès lors que l’on a activé une tâche, l’onglet Task List se vide et laisse apparaître tous les fichiers sur lesquels nous sommes en train de travailler. L’intérêt est que si l’on change en cours de route de tâche, la nouvelle tâche repartira d’un contexte vide et, en revenant sur notre première tâche, on récupérera notre contexte avec tous nos fichiers modifiés.

Productivity

L’idée ici est de gagner du temps en ayant tout de suite à sa disposition les bons outils intégrés dans son environnement de travail. En effet, avoir plus d’une dizaine d’outils répartis sur son IDE, dans son navigateur, sur son desktop… cela donne des alertes un peu n’importe où Il faut donc passer d’un patchwork à un integrated toolset.

Par défaut, Mylyn gère un nombre assez important de bugtrackers et d’outils en tout genre avec dans le désordre : Bugzilla, Jira, Bamboo, Crucible, Trac, Mantis, Hudson, Egit, CVS…

Pour la récupération des informations de l’outil, prenons par exemple Jira, il est possible de définir ses propres requêtes afin de ne récupérer qu’une certaine partie des bugs. Pour la saisie d’un bug, on dispose d’un éditeur Rich Task Editor pour la saisie des informations liées au bug (OS, version…) et pour la partie commentaire on dispose de l’éditeur WikiText qui nous permet d’écrire de la syntaxe Wiki.

Toujours en terme de productivité, il est possible d’organiser ses requêtes ou ses outils en Working Sets. On pourra aussi exporter ses contextes avec de les partager avec toute l’équipe.

Traceability

Ce concept découle du point précédent. On peut ainsi pour une tâche donnée récupérer toute les informations utiles du type qui, quoi et pourquoi, tout étant regroupé en un seul point.

Démo

Vient ensuite une petite démo avec un projet directement connecté sur le bugtracker de SpringSource :

Code2Cloud

Pour terminer, Oliver nous parle de Code2Cloud, la solution complète de SpringSource pour simplifier la vie du développeur (annonce faite au SpringOne2GX 2010).

Pourquoi parler de Code2Cloud ? Bugzilla, Git, Hudson, STS mais surtout…. Mylyn ! Olivier propose l’exemple de son intégration avec Spring Insight. On pourra ainsi configurer Spring Insight pour créer automatiquement un bug dans le bugtracker pour toute exception levée par l’application. Le bug sera bien sûr rempli avec la stack trace dans le bon champ, les classes impactées, OS/versions… Tout ceci toujours prévu pour le premier trimestre 2011.

Pour conclure

A noter enfin que Mylyn sous-projet de l’IDE Eclipse est devenu top level Eclipse project depuis mi-Septembre. Il rejoint entres autres WTP et EMF dans cette short list de projets qui représentent les secteurs clés d’Eclipse.

L’outil est bon mais pour ma part un point très gênant réside toujours : Un changement de contexte ne met pas de côté les changements effectués à la manière d’un git stash que l’on pourrait récupérer plus tard avec un pop. Si vous connaissez un plugin ou une petite commande qui fait ça, n’hésitez pas à commenter !

Scala continue sa tournée des JUG ! Après Paris et Rennes, c’est la ville de Tours qui proposera ce mercredi 3 novembre une soirée dédiée à ce langage alternatif pour la JVM.

A cette occasion, je présenterai :

• Les origines de Scala.
• Des exemples de code (live).
• Les différents outils et frameworks disponibles sur le marché.
• Les difficultés et les freins à son adoption.
• Ce qui nous attend dans les prochaines versions.
• Les entreprises qui l’utilisent.

Les inscriptions de passent par ici. Venez nombreux !

La deuxième partie de soirée a suscité quelques questions. Ce fut très constructif. De nombreux sujets ont été abordés tels que l’intégration de modules Scala dans une application Java, les performances… Mention spéciale troll à Nicolas pour sa question sur les pointeurs de fonction de Microsoft en 2001 !

Cette soirée s’est poursuivie dans un bon petit restaurant rue St Georges, où, entre autres, nous avons discuté des méthodes agiles, de diagrammes de classes ayant des formes de Dalaï Lama ou bien encore de Mammouth (pour de plus amples informations, demandez à Nicolas, il est expert dans ce domaine !).

Enfin pour ceux qui hésiteraient à se rendre au Breizh JUG, nous vous y encourageons fortement. Vous y rencontrerez des personnes avec lesquelles les échanges sont enrichissants et il y règne une très bonne ambiance.

Vous trouverez les slides de notre présentation à cette adresse, ainsi que la vidéo sur Parleys à cette adresse.

Merci encore au Breizh JUG !

Et, comme la dernière fois, cela se passera chez Xebia dans nos locaux d’Haussmann.

Voici le menu de la soirée avec une présentation d’Alexis Agahi et une autre de François Armand (annonce disponible ici) :

—

La seconde session aura lieu chez Xebia à 19h30 le mercredi 30 juin (et non plus le 17 ou le 24 comme prévu initialement, désolé pour la confusion).

Nous avons prévu deux présentations:

• La 1ère présentation sera « De Java à Scala : premier retour d’expérience » présentée par Alexis Agahi. La présentation (entre 40min et 1h) sera orientée developpeur Java et sera donc abordable pour tous.
• La seconde présentation, par François Armand, abordera les collections de Scala 2.8. Ce sera une présentation assez générale, avec les différentes classes et tout le bonheur qu’elles apportent.

Notez bien l’adresse :
Xebia
156 boulevard haussmann à Paris
Immeuble A
7e étage

Les places étant limitées, veuillez vous inscrire à l’adresse suivante : http://doodle.com/zds5ka5qqa3ndnp5.

—

—

Il s’agit d’une présentation que j’ai déjà faite au Boston Area User Group il y a quelques temps (et amélioré depuis). Pour le PSUG, j’aurai deux heures au lieu d’une. Je prévois donc de rendre cette présentation accessible à des purs java-istes ou des débutants Scala. J’utiliserai tout de même à la fin des fonctionnalités avancées de Scala, mais que je prétends faciles à l’utilisation.

Je ne ferai que du live-coding et je n’utiliserai aucun slide. Ce sera l’occasion de revenir sur des outils qui n’ont pas été vraiment explorés pendant la soirée Scala au ParisJUG (en particulier sbt).

Voici le plan de la présentation :

• je reviendrai d’abord sur le concept d’injection de dépendances et comment on fait ça à l’ancienne (ou plutôt, comment on ferait en Java). Je parlerai rapidement d’immutabilité et de typage statique ici.
• ensuite, je montrerai que les frameworks classiques venant du monde Java fonctionnent très bien avec Scala. Je laisse aux participants le choix du framework sur ce lien [1]. Je reviendrai notamment sur leurs limites dans le contexte de Scala.
• enfin, retour à du Scala pur (et pas forcément dur). Nous reviendrons entre autres sur le Cake Pattern. Mais surtout, nous jouerons ensemble avec le cocktail détonnant suivant : traits, mixins, structural typing et closures.

—

A noter toutefois que nous n’avions pas couvert sbt lors de la soirée Scala du Paris JUG mais que cet oubli (volontaire ) a été rattrapé par 2 fois avec une présentation générale du produit ainsi qu’un exemple de configuration pour Eclipse et IDEA.

Malheureusement pour les retardataires, la soirée affiche complet depuis plusieurs jours… Donc, pour ne pas rester sur la touche la prochaine fois, n’oubliez pas de vous abonner à la mailing-list du PSUG !

(surtout les miens )

Nous allons ainsi entrevoir le mécanisme de plugin de sbt ainsi que l’application de plugins sur un projet sbt. Pour celles et ceux qui connaissent un minimum ces deux environnements de développement, rien de bien sorcier : ajouter une facet Scala au projet, définir certains répertoires en tant que répertoires sources, d’autres en tant que répertoires de tests, définir _lib_managed_ en tant que dossier de librairies… Il est donc tout à fait possible de faire tout ceci à la main en quelques minutes. L’idée ici est vraiment de jouer avec quelques plugins sbt et les intégrer à un projet existant.

Si vous êtes plutôt Emacs ou Vim, je vous renvoie sur le site de sbt pour la configuration à adopter.

Eclipse

Nous allons importer notre projet à l’aide du plugin SbtEclipsify. Ce plugin prend en charge la création de tous les fichiers nécessaires à Eclipse .project,.classpath…) afin que le projet soit importable et intégralement configuré. Il n’est actuellement disponible sur aucun repository, il va donc falloir soit télécharger le Jar et le déposer dans son repository local, soit récupérer le projet et utiliser sbt pour le compiler et le publier en local. Nous partirons sur ce deuxième choix (pour utiliser quelques petites commandes sbt).

Tout d’abord, nous allons récupérer le projet à l’aide de la commande git clone :

$ git clone http://github.com/musk/SbtEclipsify.git

Ensuite, nous allons démarrer sbt et faire un update pour mettre à jour toutes les dépendances du projet :

$ sbt
$ update

Nos dépendances étant à jour, nous allons pouvoir compiler et publier le projet à l’aide de la commande publish-local (image tronquée) :

$ publish-local

Maintenant que le Jar est disponible dans notre repository, nous allons pouvoir configurer notre projet avec cette nouvelle dépendance. Pour cela, créons le fichier project/plugins/Plugins.scala et ajoutons le plugin sbt-eclispsify :

import sbt._
 class MySbtProjectPlugins(info: ProjectInfo) extends PluginDefinition(info) {
       lazy val eclipse = "de.element34" % "sbt-eclipsify" % "0.5.2-SNAPSHOT"
 }

Dernière étape avant de tout builder : modifier notre fichier projet, dans la classe project/build/MyProject.scala, pour marquer notre projet en tant que projet eclipsifiable à l’aide du trait Eclipsify :

import sbt._
import de.element34.sbteclipsify._
class MyProject(info: ProjectInfo) extends DefaultProject(info) with Eclipsify {
   // ...
}

Voilà, tout est prêt, démarrons sbt et lançons la commande eclipse après avoir mis à jour nos dépendances pour notre projet (à l’aide de la commande update) :

$ sbt
$ update
$ eclipse

That’s all ! Il n’y a plus qu’à faire un import dans Eclipse de votre projet. A partir de maintenant, la commande eclipse ne devrait plus vous servir. Il faudra dès lors passer par reload lors de modifications concernant vos plugins ou vos dépendances pour mettre à jour votre contexte sbt et bien sûr update pour la mise à jour de vos dépendances.

A noter que d’autres plugins existent :

• sbt-eclipse-plugin : ce plugin n’est ni plus ni moins qu’un container de type classpath qui pointe vers le dossier lib_managed. L’outil fonctionne très bien mais les manipulations sont à effectuer à la main et aucune opération en ligne de commande (pour automatisation) n’est disponible pour l’instant. A surveiller donc ;
• IvyIDE (avec la procédure d’installation ici).

IntelliJ IDEA

Plusieurs plugins existent et, pour ma part, j’ai choisi le plugin sbt-idea-plugin. A noter que celui-ci fournit son propre repository maven donc pas de git clone sur le projet avec un publish-local comme pour SbtEclipsify. Tout se fait cette fois-ci très simplement !

Comme pour SbtEclipsify, le plugin fournit un trait qu’il faudra ajouter à sa classe projet qui lui permettra d’avoir la commande idea disponible dans le shell.

Il faut donc tout d’abord se rendre dans la classe project/plugins/Plugins.scala et ajouter ces quelques lignes. Elles ajouteront un repository distant et la dépendance du plugin :

val repo = "GH-pages repo" at "http://mpeltonen.github.com/maven/"
val idea = "com.github.mpeltonen" % "sbt-idea-plugin" % "0.1-SNAPSHOT"

Maintenant que notre plugin est prêt à l’emploi, nous allons l’ajouter dans la configuration de notre projet (toujours au niveau de project/build/MyProject.scala). Cela nous donne :

import sbt._
import de.element34.sbteclipsify._
class MainProject(info: ProjectInfo) extends ParentProject(info) with IdeaPlugin {
  lazy val myProject = project("myproject", "My Project", new DefaultProject(_) with IdeaPlugin)
   // ...
}

Grosse différence avec Eclipse : le plugin fonctionne par défaut, même si l’on a qu’un seul project, comme une arborescence de projets. Ainsi, nous aurons un projet parent composé de sous-projet(s). Pour utiliser ce plugin, nous allons donc (cf. code ci-dessus) créer un projet MainProject en tant que conteneur de projet en étendant ParentProject. Ensuite, nous créerons dans ce projet sbt un projet de type DefaultProject qui contiendra notre code ({{src/main/scala}}…).
Notez que les deux projets utilisent le trait IdeaPlugin. En effet, IntelliJ IDEA gère parfaitement l’arborescence de projets. Nous aurons donc les deux projets importés dans l’IDE avec la vue projets qui nous affichera le projet parent et notre projet.

A ce niveau, comme pour Eclipse, tout est prêt ! Donc un update et cette fois-ci un idea pour lancer le plugin :

$ sbt
$ update
$ idea

Et le résultat avec notre projet parent contenant notre sous-projet une fois importé dans IntelliJ IDEA (par le fichier .ipr) :

Les deux ?

Et si tout comme moi, cela vous arrive de switcher de l’un à l’autre selon votre humeur (tiens aujourd’hui j’ai envie de faire du Eclipse ), vous pourrez bien évidemment configurer votre projet pour qu’il accueille ces deux environnements de développement. La configuration finale sera un mix de ce que l’on a vu précédemment. En ne prenant pas le projet parent en tant que projet Eclipse (car il ne les gère pas très bien), cela nous donne tout simplement :

class MainProject(info: ProjectInfo) extends ParentProject(info) with IdeaPlugin {
   lazy val myProject = project("myproject", "My Project", new MyProject(_) with IdeaPlugin with Eclipsify)
   class MyProject(info: ProjectInfo) extends DefaultProject(info) {
      // Put here MyProject dependencies
   }
}

Cette configuration fonctionne out-of-the-box pour IntelliJ IDEA, par contre pour Eclipse un problème de build path subsiste. Il est directement lié à cette arborescence de projets (module / sous-module) qui n’est actuellement pas géré par le plugin :

Il faudra donc modifier à la main le build path de notre projet. Une fois celui-ci modifié, le projet sera opérationnel pour Eclipse et vous n’aurez plus qu’à faire des sbt update pour mettre à jour vos dépendances :

Dernière chose, entre la configuration pour avoir les deux plugins et celle d’IntelliJ IDEA standalone : notez la différence concernant le sous-projet MyProject avec non plus l’utilisation directe d’une nouvelle instance de DefaultProject mais la création et l’instanciation d’une nouvelle classe MyProject qui étend DefaultProject. Cela va nous permettre de définir des dépendances uniquement au niveau du sous-projet et ainsi ne pas tout mettre au niveau du projet parent. Il est dès lors possible d’ajouter plusieurs sous-projets à MainProject et ainsi se retrouver avec le même type d’arborescence de modules que l’on retrouve dans nos projets maven.

Vous pouvez toujours récupérer le petit projet scala-samples qui possède cette double configuration idea/eclipse.

Le sujet de cet article n’est autre que le framework Scala qui monte (très vite) en ce moment à savoir sbt (pour simple-build-tool). Nous verrons dans cet article ce qu’est sbt, ses différentes fonctionnalités et en quoi cet outil va nous être très utile dans nos développements quotidiens.

Yet Another Build Tool ?

sbt est un outil de build qui se veut simple d’utilisation. Son objectif est de fournir des fonctionnalités basiques et avancées très simples à implémenter sur un projet Scala ou Java.
On pourra dès lors n’utiliser notre IDE qu’en tant qu’éditeur de texte et laisser à sbt les tâches de compilation, de tests unitaires sur une ou plusieurs versions de Scala (très utile pour les concepteurs d’API), changer de version de Scala en cours de développement…

La configuration de se fait en Scala à l’aide d’un DSL qui vous permettra de spécifier ses dépendances de projet, ses plugins et beaucoup d’autres paramètres. Le gestionnaire de dépendances utilisé est ivy. Il est possible pour son projet de spécifier un repository maven ou autre et ainsi n’avoir qu’un seul repository centralisé sur sa machine.

A notez que sbt tourne au minimum sur Java 5.

Fonctionnalités

Générales

L’outil propose plusieurs fonctionnalités en standard dont :

• Configuration du projet en Scala,
• Compilations et tests en continu,
• Support de projets Java et Scala,
• Génération de la scaladoc,
• Frameworks ScalaCheck, Specs et ScalaTest supportés par défaut,
• Démarrage du REPL avec projet et dépendances dans le classpath,
• Exécution de tâches en parallèle (dont les tests),
• Gestion de dépendances inline, ivy ou maven.

Nous allons regarder plus en détail les actions possibles dans sbt, la configuration d’un projet sbt ainsi que les quelques cas d’utilisation.

Actions

Il y a plusieurs manières d’utiliser sbt. Soit en lançant la console sbt pour effectuer nos actions unitairement dans l’environnement sbt, soit en mode batch avec certaines commandes prédéfinies dans l’appel à sbt. Il est aussi possible (nous le détaillerons plus tard dans l’article) de mettre une action en attente de modification de fichiers pour ensuite être lancée.

// Console
$ sbt
> compile
> test
> ...
// Batch
$ sbt clean compile "get sbt.version"
// Wait
$ sbt
> ~ test

Il est possible de lancer une action sur une version de Scala spécifique. Ainsi, si l’on souhaite par exemple compiler notre projet en Scala 2.8.0 alors que notre projet est actuellement en Scala 2.7.7, nous ferons :

// 2.7.7 by default
> compile
// Force 2.8.0.Beta1 version
> ++2.8.0.Beta1 compile

Les actions possibles sont assez nombreuses sachant que vous connaissez déjà bon nombre d’entre elles :

• clean, compile, exec, jetty-run, package, test… qui font ce que vous savez ,
• update pour mettre à jour vos dépendances,
• sh qui invoque le shell unix pour par exemple exécuter un find,
• nombreuses actions sur test-* et package-* avec plusieurs déclinaisons (all, docs, project, failed, quick...),
• console et console-quick pour démarrer l’interpréteur Scala (REPL), la différence entre les deux se faisant sur le classpath chargé au démarrage,

Concernant les actions qui touchent à l’environnement sbt, nous avons :

• exit, quit, help, info, debug, trace, warn, error…,
• reload qui permet de recharger les modifications effectuées sur la configuration de notre projet,
• current qui nous donne le nom du projet ainsi que le niveau de log actuel,
• projects qui liste tous les projets disponibles en cas d’arborescence de projets,
• ; A ; B qui exécute une action A et qui, si elle réussie, exécute une action B.

Il est bien sûr possible de créer ses propres actions en construisant une tâche Task de la manière suivante :

lazy val foo = task { log.info("Foo !"); None }

La tâche foo sera alors créée et disponible dans la console sbt. A noter qu’une syntaxe minuscule et une séparation par tiret est respectée pour les noms de tâche, ainsi une variable nommée fooBar donnera comme tâche foo-bar.

Il est possible de définir sur quelle phase du build la tâche doit être lancée et de fournir une description de la tâche :

lazy val jars = task { ... } dependsOn(compile, doc) describedAs("Package classes and API docs.")

Il est aussi possible de modifier des actions existantes comme clean, test ou bien encore package mais aussi de modifier la dépendance de ces tâches par rapport à d’autres tâches. Vous pouvez aussi faire de l’exécution conditionnelle pour des tâches générant des fichiers. Différentes stratégies existent, on pourra ainsi définir qu’une tâche ne doit être exécutée que si les fichiers cibles qu’elle génère sont périmés ou bien constamment générer ces fichiers cibles.

Configuration

L’arborescence d’un projet sbt est la suivante :

lib/
lib_managed/
project/
   boot/
   build/
      MyProjectConf.scala
   plugins/
      Plugins.scala
   build.properties
src/
   main/
      scala/
      resources/
   test/
      scala/
      resources/
target/

On remarque la même arborescence de dossier que pour un projet maven à savoir src/main/scala et src/main/resources pour les sources et src/test/scala et src/test/resources pour les tests. Concernant les autres dossiers, lib vous permettra de déposer vos librairies, lib_managed contiendra vos dépendances (si aucun repository n’est spécifié), project/build votre configuration projet tandis que project/plugins vous permettra de définir les plugins que votre projet utilisera.

La définition des dépendances et la gestion des plugins se fait en Scala. Voici quelques exemples de définition de dépendances :

lazy val jetty = "org.mortbay.jetty" % "jetty" % "6.1.22"
lazy val h2 = "com.h2database" % "h2" % "1.2.121"
lazy val junit = "junit" % "junit" % "4.5" % "test"
lazy val slf4 = "org.slf4j" % "slf4j-log4j12" % "1.4.1"

Il est possible de définir un projet de type parent qui contiendra plusieurs projets (modules). La configuration pour ce type de projet est la suivante :

import sbt._
class ParentProject(info: ProjectInfo) extends ParentProject(info) {
   lazy val core = project("core", "Core project")
   lazy val client = project("client", "Client project", core) // Project based on core
   lazy val dao = project("dao", "DAO project", new DAOProject(_))
   class DAOProject(info: ProjectInfo) extends DefaultProject(info) {
      // Define here custom dependencies
   }
}

Il est aussi possible de définir sa configuration projet à partir d’un fichier maven pom.xml ou d’un fichier ivy ivy.xml. Pour cela, il suffit de les ajouter à la racine de votre projet. Ainsi, sur une commande update, sbt utilisera le fichier maven ou ivy pour gérer les dépendances du projet.

Les configurations possibles sont nombreuses. Pour une configuration plus avancée, je vous renvoie vers cette page qui détaille exhaustivement tout ce que l’on peut faire en terme de configuration dans un projet sbt, du changement de l’arborescence des dossiers aux options de compilation, package et test.

Cas d’utilisation

Triggered execution

En effet, sbt ne se résume pas qu’à un simple outil de configuration projet. Nous avons vu au début de cet article les actions possibles dans sbt, comme par exemple compile ou test. Ce sont des actions one shot qu’il faudra relancer autant de fois que l’on voudra pour, dans ce cas, compiler ou tester.

Mais, en préfixant ces actions par le caractère ~, sbt se mettra en attente de modification dans le scope de l’action et dès qu’une modification sera effectuée, l’action sera déclenchée, d’où leur nom : triggered execution. Ainsi, si une modification se produit par exemple dans src/main/scala, compile et test seront appelés car ils sont en attente de modifications sur les fichiers sources du projet.

Actuellement, trois types d’actions sont de type triggered execution :

• compilation : avec la compilation continue par ~ test-compile ou uniquement la compilation des sources dans main avec ~ compile ;
• test : avec ~ test-quick pour lancer les tests qui n’ont pas encore réussi (nouveau ou failed du tests précédent) ou qui ont été recompilés, ~ test-failed pour lancer uniquement les tests qui n’ont pas encore réussi (mais ne relance pas les tests recompilés comme ~ test-quick) et ~ test-only mytestpackage.MyTest pour lancer les tests de la classe spécifiée ;
• web-app : si vous utilisez jetty et une fois jetty lancé (jetty-run), la commande ~ prepare-webapp recompilera la webapp pour prendre en compte les modifications. Pour avoir une compilation continue totale, je vous renvoie à la section JRebel qui explique comment prendre en compte JRebel pour scanner certains dossiers à recharger dynamiquement et ainsi éviter les reloads de Jetty.

Cross building

L’autre cas d’utilisation qu’offre sbt est le cross building. Cette fonctionnalité est un véritable atout pour toute API ayant comme cible de nombreuses versions de Scala, surtout si elles ne sont pas binairement compatibles entre elles, comme par exemple Scala 2.7.7 et la prochaine version 2.8.0 (mais c’est aussi le cas entre 2.7.2 et 2.7.4).

Voyons d’abord comment utiliser une librairie packagée différemment pour cette version de Scala. L’exemple ci-dessous montre en premier le fait d’imposer la version de Scala. Le problème est que si l’on change temporairement de version de Scala dans notre projet, il risque de ne pas builder. Le second exemple nous montre que sbt peut récupérer la bonne version de la librairie en fonction de la version de Scala courante de notre projet à l’aide de la dépendance spéciale %% :

val dispatch = "net.databinder.dispatch" % "dispatch_2.7.7" % "0.7.2"
val dispatch = "net.databinder.dispatch" %% "dispatch" % "0.7.2"

Maintenant, nous allons pouvoir construire notre projet dans différentes versions de Scala en très peu de configuration et surtout en un caractère ! La définition se fait directement dans la console sbt de la manière suivante :

$ sbt
> set build.scala.versions 2.7.7 2.8.0.Beta1 2.7.5 2.7.3 2.7.2
> reload

Par défaut, sbt utilisera la première version définie comme version par défaut. Vous pouvez bien sûr changer de version à tout moment à l’aide de la commande ++version.

Et pour le cross building, il suffit de préfixer notre action par + pour qu’elle soit exécutée sur toutes les versions ciblées par notre projet :

> +package
> +publish

Point important : certaines dépendances de votre projet ne seront peut-être pas les mêmes selon les versions de Scala que vous ciblez. Il est donc important de faire un pattern matching sur les API qui pourraient poser problème :

val scalatest = buildScalaVersion match {
   case "2.7.5" => "org.scala-tools.testing" % "scalatest" % "0.9.5"
   case "2.7.2" => "org.scalatest" % "scalatest" % "0.9.3"
   case x => error("Unsupported Scala version " + x)
}

Project console

Dernier cas d’utilisation que nous verrons dans cet article, le lancement de la console avec tout le contexte de projet intégralement chargé. Ainsi, console-project démarre l’interpréteur Scala avec le projet courant chargé. On peut dès lors utiliser tous nos objets et faire quelques tests directement dans la console.
Mais ce mode permet bien plus que l’appel de nos objets, il permet aussi, entre autres, de :

• voir les options de compilation : compileOptions.foreach(println) ;
• voir tous les repository : repositories.foreach(println) et ivyRepositories.foreach(println) ;
• voir le classpath de compilation et celui des test : compileClasspath et testClasspath ;
• ou bien encore voir les dépendances de projet : mainDependencies.external, mainDependencies.libraries et mainDependencies.scalaJars.

Installation

Maintenant que vous en savez plus sur sbt, j’espère que vous avez l’eau à la bouche et que avez envie de jouer avec l’outil Nous allons donc voir comment installer la bête. Tout d’abord, rendez-vous sur cette page pour télécharger la dernière version de sbt.

Pour l’installation sous Mac, il suffit d’ajouter un fichier dont le nom sera sbt au même niveau que votre Jar sbt avec le contenu suivant :

java -Xmx512M -jar `dirname $0`/sbt-launch.jar "$@"

Il faudra ensuite ajouter dans votre path le répertoire contenant ce fichier et le Jar sbt. Exemple dans .bash_profile :

export SBT_HOME=$HOME/dev/scala/sbt
export PATH=$SBT_HOME:$PATH

Voilà, c’est installé ! Pour les accros de la ligne de commande, voici un mode d’installation fait pour eux (unix) qui est d’ailleurs expliqué sur le site de sbt qui installe sbt dans /usr/local/bin/ :

$ cd ~
$ wget http://simple-build-tool.googlecode.com/files/sbt-launcher-0.7.3.jar
$ sudo mv sbt-launcher-0.5.6.jar /usr/local/bin/sbt-launcher.jar
$ echo "java -Xmx512M -jar /usr/local/bin/sbt-launcher.jar "$@"" | sudo tee /usr/local/bin/sbt
$ sudo chmod +x /usr/local/bin/sbt

En ce qui concerne l’installation Windows, cela se passe ici.

Nous allons maintenant tester l’installation. Commençons par créer un dossier, déplaçons nous dedans et lançons la commande sbt en répondant s à la question de création de projet (pour scratch qui fera une configuration rapide du projet). Faisons ensuite un compile même si aucune source n’existe actuellement :

$ mkdir foobar-project
$ cd foobar-project
$ sbt

Build successful ! Ajoutons maintenant un fichier PrintMessage.scala dans src/main/scala qui affichera un message dans la console sur la tâche run :

object PrintMessage {
  def main(args: Array[String]) = println("Foobar Scala !")
}

Et maintenant lançons notre message à l’aide de l’action run :

$ sbt run

Vous voilà prêt pour utiliser sbt !

Conclusion

Cet outil est déjà très utilisé par plusieurs projets Scala open-source (dont par exemple akka). Les possibilités sont très nombreuses et n’ont pas toutes été énumérées dans le présent article. Je vous renvoie vers le wiki de sbt pour un détail complet des fonctionnalités de l’outil.

Ce qui ressort après quelques heures d’utilisation c’est l’extrême simplicité d’utilisation de l’outil, la simplicité de configuration d’un projet et la puissance d’avoir en tâche de fond les tests en continu. Certaines personnes vont même jusqu’à se désynchroniser totalement de leur IDE qui ne devient dès lors qu’un simple éditeur de texte laissant à sbt la compilation, les tests et l’exécution. D’autres nous expliquent comment configurer Eclipse pour faire du debug sur des tests lancés depuis la console sbt.

Un petit exemple de projet sbt est d’ailleurs disponible sur mon GitHub. A vous de jouer !

Merci aussi pour la troisième mi-temps qui a été l’occasion de retours positifs sur les présentations de la soirée et qui nous a permis de constater que ces dernières ont donné envie à beaucoup de personnes de s’essayer à Scala. En effet, comme l’explique Nicolas Martignole dans son article, cette troisième mi-temps permet de poursuivre les discussions et les débats que les présentations engendrent mais aussi de rencontrer des personnes passionnées comme nous le sommes.

Vous trouverez les slides de notre présentation à cette adresse.

Merci encore et à bientôt !

Parce que toutes les bonnes choses ont une fin, voici venir pour moi la dernière session de ce Devoxx 2009 avec le Projet Lombok présenté par les développeurs de l’outil (Roel Spilker et Reinier Zwitserloot).

L’objectif de ce produit est de nous faire gagner du temps et d’améliorer la lisibilité de nos classes. Comment ? Et bien, moyennant quelques annotations, l’outil va par exemple générer pour nous les méthodes toString, equals et hashcode mais aussi les getters et setters de notre POJO. Certes, nos IDEs nous proposent déjà ce travail mais il subsiste 2 différences de taille :

• ce n’est plus au développeur d’appeler les Generate xxx d’eclipse, la génération de ces méthodes se fera à l’import des annotations ou à la sauvegarde du fichier ;
• mais surtout, la génération de ces méthodes ne se fait pas dans le code source Java mais directement dans le Bytecode, nos POJOs restent donc clean.

Côté IDE

Prenons par exemple une classe standard avec une propriété firstname et une propriété lastname. En y ajoutant simplement l’annotation @Data (décrite ci-après dans l’article), nous pouvons constater que la vue Outline d’eclipse s’est bien mise à jour avec les méthodes getFirstName, setFirstName, toString etc… . Bien que non implémentées, ces méthodes existent et sont totalement fonctionnelles au sein du projet dans eclipse :

Côté code

Plusieurs annotations nous sont proposées. Chacune possède sa spécificité / spécialité :

• @Getter et @Setter avec prochainement @Property qui fera les 2 ;
• @ToString ;
• @EqualsAndHashCode ;
• @Data qui regroupe les 4 annotations précédentes ;
• @Synchronized qui nous permet de simplifier l’écriture de bloc synchronized ;
• @SneakyThrows qui nous permet de ne pas écrire de try catch ou de throws dans/sur notre méthode. L’exemple décrit ci-après est l’UnsupportedEncodingException du constructeur String avec par exemple UTF-8 comme Charset : cette exception ne pourra jamais être levée car la JVM doit fournir UTF-8 ;
• @Cleanup qui nous enlève le lourd poids de devoir appeler la méthode close sur des Stream dans différents try finally.

Toutes ces annotations sont bien sûr paramétrables (AccessLevel, exclude, of, staticConstructor…) ce qui nous permet entre autres d’inclure ou d’exclure certains champs du processus de génération (idéal pour un equals ou un toString).

Ces annotations paramétrables (voir AccessLevel, exclude, of, staticConstructor etc…) influent directement sur le code généré. Ainsi on peut régler à sa guise, portée, visibilité, ou utilisation des attributs de la classe. Cela peut être très pratique pour des méthodes telles que equals ou hashcode.

Voici un exemple de code d’une classe Java lombok-ifée :

// @Data does @Getter, @Setter, @ToString and @EqualsAndHashCode
@ToString
@EqualsAndHashCode
public class MyPojo {
	private @Getter @Setter(AccessLevel.PUBLIC) String firstname;
	private @Getter(AccessLevel.PROTECTED) @Setter(AccessLevel.PRIVATE) String lastname;
	@Synchronized
	@SneakyThrows({UnsupportedEncodingException.class, IOException.class})
	public void init() {
		setFirstname("foobar");
		@Cleanup InputStream in = new FileInputStream("c:/input.txt");
		@Cleanup OutputStream out = new FileOutputStream("c:/output.txt");
	    	byte[] bytes = new byte[10000];
	    	while (true) {
	       		int r = in.read(bytes);
	       		if (r == -1) break;
	       		out.write(bytes, 0, r);
	    	}
		setLastname(new String("abc".getBytes(), "UTF-8"));
	}
	public static void main(String[] args) {
		MyPojo myPojo = new MyPojo();
		myPojo.init();
		System.out.println(myPojo.toString());
		System.out.println(myPojo.equals(new MyPojo()));
	}
}

Incubation

L’équipe travaille actuellement sur d’autres annotations et plus globalement sur des améliorations de syntaxe Java :

• @Delegate sur une propriété d’une classe faisant que cette classe hériterait des méthodes de cette propriété. On pourrait donc avoir une classe qui implémente l’interface Iterable<Something> et qui aurait une propriété @Delegate Iterable<Something> listDelegate = new ArrayList<Something>() : la classe récupère ainsi toutes les méthodes de l’objet listDelegate et n’a ainsi absolument plus besoin de définir toutes les méthodes de l’interface Iterable<Something> côté Java (par contre côté Bytecode tout est là !) ;
• @Mixin(MyClass.class) qui permet de rajouter dynamiquement du comportement à une classe, en l’occurrence les méthodes de MyClass dans la classe qui aurait définit cette annotation ;
• Le String multi-lignes avec les 3 guillemets d’ouverture et les 3 autres de fermeture avec au milieu autant de retours à la ligne que vous le souhaitez ;
• La création de liste simplifiée à partir d’une autre liste avec une syntaxe très particulière : Mountain m : mountainList where (m.getAltitude() > 1000) select (m.getName()) qui ferait qu’en une ligne on passe d’une liste de montagne à une liste de nom de montagne.

Limitations

Malgré les avancées notables de cette solution, des difficultés subsistent. L’intégration avec les IDEs, notamment pour les fonctions de refactoring, est à compléter. Car dans ce cas, le code n’existant pas (dans le fichier java), il est ardu de faire du refactoring.

Pour l’instant, seul Eclipse est supporté par Lombok. Cependant l’équipe travaille au support pour Netbeans et depuis peu pour IntelliJ IDEA Community Edition.

Les fonctionnalités sont charmantes, mais on peut constater que la route est encore longue. D’ailleurs, les speakers le reconnaissent volontiers quand ils annoncent avec humour que : « la montagne est haute mais pas insurmontable »

Conclusion

Un outil à surveiller donc, et qui pourrait bien finir dans notre classpath une fois stabilisé, compatible avec les IDEs du marché et production-ready.

En attendant, vous pouvez jouer avec en le récupérant à cette url. Et n’oubliez pas d’exécuter le JAR afin de patcher votre eclipse.

Comme énoncé dans notre résumé de la keynote du mercredi, la star de ce Devoxx 2009 est clairement JEE6. Et, au premier rang avec mon superbe t-shirt « I Love Spring », j’ai pu profiter d’une présentation générale de cette nouvelle version de JEE par Antonio Goncalves et la petite caricature de Rod Johnson .

Introduction

Tout d’abord quelques chiffres autour de JEE6 :

• une sortie prévue le 10 décembre 2009
• 11 ans de JEE (JPE / J2EE / JEE)
• le plus grand intervalle entre 2 versions (3 ans et demi avec JEE5)
• 28 spécifications

Un récapitulatif nous montre les différentes spécifications utilisées (ainsi que quelques technos Java SE 6) avec en jaune les nouvelles spécifications et en noir les montées de version majeures :

Il y en a pour tous les goûts : de l’injection, du back-end et du web et cela a de quoi séduire.

Certaines spécifications sont marquées comme pruned par JEE6 et pourraient éventuellement disparaître dans JEE7. Nous parlons ici des Entity CMP 2.x, de JAX-RPC, JAX-R et de JSR-88 (Java EE Application Deployment).

Antonio nous fait ensuite un rapide tour d’horizon des spécifications marquantes de ce JEE6.

Web Profile

Web Profile est un sous-ensemble de la plateforme JEE orienté Web. On compte parmi les spécifications retenues JSF, Servlet, JSP, JPA, JTA, JCDI, @Inject ou bien encore EJB Lite. La liste complète en image :

EJB Lite

De même que pour Web Profile, EJB Lite est un sous-ensemble d’EJB 3.1, le tout packagé dans un fichier War. Retenues dans EJB Lite :

• Local Session Bean
• Injection
• CMT / BMT
• Interceptors
• Security

Out donc les Messages Driven Beans, les Remote Interfaces ou bien encore les Timer Services.

Managed Beans

Les Managed Beans sont de simples POJOs gérés par le container (lightweight model). Ces beans supportent un ensemble de services basiques (par annotations) dont :

• Injection (@Resource …)
• Life-Cycle (@PostConstruct, @PreDestroy)
• Interceptor (@Interceptor, @AroundInvoke)

@javax.annotation.ManagedBean
public class MyPojo {
   @Resource
   private DataSource dataSource ;
   @PostConstruct
   private void init() {
      // ...
   }
   @Interceptor(LoggingInterceptor.class)
   public void perform() {
       // ...
   }
}

Bean Validation

Antonio nous parle ensuite de Bean Validation, spécification qui va nous permettre de définir des contraintes directement sur nos POJOs par annotations. L’accroche : constrain once, validate anywhere ! Nous pouvons donc ajouter des validations de type @NotNull, @Size ou autres sur nos propriétés de bean. Il est aussi possible de définir nos propres validateurs.

Cette spécification définit ainsi un standard de validation pour Java, Bean Validation étant déjà supportée par JPA 2.0 et JSF 2.0. On a ainsi une validation qui part de la base de données et va jusqu’à la couche cliente.

JAX-RS

Un peu de RESTful dans JEE avec JAX-RS qui passe au passage en version 1.1 pour supporter les EJBs. L’API reste bien sûr orientée POJO et annotations. Voici un exemple d’intégration de JAX-RS avec un EJB :

@Path("/users/{userId}")
@Stateless
public class UserResource {
   @GET @Produces("image/jpeg")
   public byte[] getPhoto() {
      // ...
   }
   @GET @Produces("text/xml")
   public String getUser(@PathParam("userId") String id) {
      // ...
   }
}

@Inject et CDI (Context and Dependency Injection)

Nous vous avons déjà beaucoup parlé de ces JSRs (ici, ici, ici mais aussi là et encore là).
@Inject, @Named, @Qualifier, @Scope ou bien encore @Singleton, voici les annotations de JSR-330 que nous allons pouvoir utiliser.
Quant à CDI (JSR-299), qui utilise @Inject, elle nous propose un set de services utilisables par nos composants EE (servlets, beans…). Elle nous permet aussi d’utiliser nos EJBs directement dans JSF en tant que backing beans.
Évidemment, le contenu de ces spécifications est beaucoup plus large et nous n’avons ici qu’un rapide résumé.

Mais aussi…

Parmi les autres nouveautés, on peut citer en vrac :

• Appels asynchrones avec @Asynchronous avec un retour void ou Future<T> ;
• Annotation @Singleton ;
• Annotation @Cacheable avec toute l’API de cache (contain, evict ou evictAll) qui permet le support d’un cache de second niveau ;
• Embeddable Container, API qui permet d’initialiser le container, de récupérer les contextes… faisant qu’il est possible de le faire tourner dans un environnement Java SE (par exemple une application Swing), ce ne sera qu’un JAR dans votre classpath ;
• Timer Service pour gérer la planification de tâche avec l’annotation @Schedule ;
• Fichier web.xml optionnel grâce entre autres aux annotations @WebServlet, @WebFilter,@WebListener ou bien encore @WebInitParam ;

Conclusion

L’opération séduction fonctionne plutôt bien pour JEE6 si l’on écoute les différents commentaires des conférenciers en sortie de session. La simplicité et facilité d’utilisation des EJBs, le profile web ou encore les injections ont vraiment convaincus et nombreux sont ceux qui attendent désormais avec impatience ce 10 décembre 2009. En effet, il n’y a plus qu’à tester et à voir si JEE6 tient vraiment toutes ses promesses…

Deuxième partie de nos billets Devoxx consacrés à Scala. Après les acteurs, c’est au tour de la librairie ScalaTest de faire son show.

Au cours de cette présentation, nous verrons les fonctionnalités de cette librairie, son intégration avec les outils actuels du marché (comme JUnit ou TestNG) mais aussi l’intérieur de la bête. Cela nous permettra de mettre les mains dans ScalaTest ! Le mot d’ordre de la session : productivité !

Présentation

ScalaTest est un framework open-source de tests unitaires pour la plateforme Java. Il est possible de tester à la fois des classes Java mais aussi des classes Scala. L’objectif est d’augmenter la productivité du développeur qui écrira moins de lignes de test; Ces lignes étant plus claires que si elles avaient été écrites en Java. Moins de lignes, plus claires que du Java ? Je veux des exemples…

Le Trait principal de l’API est Suite qui fournit une multitude de méthodes tests et utilitaires comme run, runNestedSuites ou bien encore withFixtures (les détails des méthodes et de ce qu’elles font se trouvent sur la scaladoc du projet). De là découlent des classes concrètes comme JUnitSuite, JUnit3Suite, JUnitWrapperSuite, TestNGSuite ou TestNGWrapperSuite. Plusieurs Matchers nous permettrons d’écrire nos tests avec des facilités d’écriture (DSLs). On retiendra AssertionsForJUnit, ShouldMatchersForJUnit (qui donne vraiment l’impression que l’on écrit notre test comme on écrirait des phrases en anglais) mais aussi MustMatchersForJUnit.

Petite comparaison

Le premier exemple nous montre les nuances entre différentes APIs de tests unitaires dont JUnit 3 et JUnit 4 et avec ScalaTest :

String s = "hi" ;
// JUnit 3
try {
   s.charAt(-1);
   fail();
} catch (StringIndexOutOfBoundException e) {
   // Expected, so continue
}
// JUnit 4
@Test(expected= StringIndexOutOfBoundException.class)
public void testPassingANegativeToCharAt() {
   s.charAt(-1);
}
// ScalaTest
intercept[StringIndexOutOfBoundException] {
   s.charAt(-1)
}

Les non-habitués auront l’impression de manipuler une syntaxe du langage comme le synchronized Java (qui a la même écriture), alors qu’en fait il ne s’agit que d’un appel à une méthode qui prend en entrée une fonction à exécuter. La méthode intercept exécute tout de suite la fonction en paramètre et catch une éventuelle exception. Celle-ci sera comparée au type d’exception attendu (ici StringIndexOutOfBoundException). Le plus gros du travail aura été de récupérer le type de (T<:Any) de intercept afin de comparer la classe de l'exception levée à celle attendue (T). Pour cela, les développeurs ont utilisé la classe Scala scala.reflect.Manifest qui permet d'accéder à l'erasure du type T.

Le ton est donné, nous sommes dans cette salle pour apprendre à utiliser la librairie mais aussi pour mettre les mains dans ScalaTest et voir l'implémentation de quelques fonctionnalités de l'outil (intercept, mock...). En gros, des conférenciers les yeux rivés sur les slides et heureux d'être là !

Les mocks

Dans ScalaTest, les mocks ne sont pas en reste. Pour les utilisateurs d'EasyMock, ScalaTest propose une autre manière d'écrire ces mocks avec un wrapping des appels à replay et verify. Encore une fois, cela passe par une méthode qui prendra en entrée une fonction et fera l'appel à replay ou verify à la fin de l'exécution de la fonction :

// Wrap replay
expecting {
   mockCollaborator.documentAdded("document")
}
// Wrap verify
whenExecuting(mockCollaborator) {
   classUnderTest.addDocument("document", new Array[Byte](0))
}

You should do that !

Bill enchaîne ensuite avec le matcher should et l'exemple nous montrant que ce n'est pas de la magie mais juste une bonne utilisation des sucres syntaxiques de Scala :

map should contain key 'a'
// Equivalent to
map.should(contain).key('a')

Ainsi, en écrivant l'API d'une certaine manière, on obtient des méthodes qui peuvent être appelées sans point ni parenthèses. D'autres exemples nous sont donnés :

"A Stack (when empty)" should "be empty" in {
   emptyStack should not be "empty" // This should fail
}
it should "complain on peek" in {
   evaluating( emptyStack.peek ) should produce [IllegalStateException]
}
ignore should "complain on pop" in {
   evaluating( emptyStack.pop ) should produce [IllegalStateException]
}
myInt should be > 0
myOtherInt should be === 0

GivenWithThen

Dernière subtilité concernant ScalaTest avec le Trait GivenWithThen. Celui-ci permet de documenter les tests mais, à la différence d'un commentaire dans le code, ceux-ci apparaîtront dans le rapport d'exécution. Exemple avec le résultat à l'exécution en image live :

when("pop is invoked on the stack")
var result = stack.pop()
then("the most recently pushed element should be returned")
assert(result === 2)
and("the stack should have one less item than before")
assert(stack.getSize === oldSize - 1)

Conclusion

Avec cette version 1.0, nous retiendrons :

• Une meilleure intégration avec JUnit,
• Une meilleure intégration avec JMock, EasyMock et Mockito,
• Le trait GivenWithThen,
• Plusieurs nouvelles FixtureSuite qui facilitent la programmation fonctionnelle et l'injection de fixtures directement dans les tests.

ScalaTest 1.0 se télécharge sur cette page, soit directement le fichier ZIP soit la dépendance Maven.

Le langage Scala était très représenté cette année à Devoxx avec une session sur les acteurs par Franck Sommers, une autre sur ScalaTest par Bill Venners ou encore celle sur le framework web Lift par Timothy Perrett. Cette dernière n’a malheureusement pas tenu toutes ses promesses : la moitié de la présentation s’est focalisée sur les spécificités du langage et une autre partie sur la déjà vue application ChatDemo en comet de David Pollack sans réelle explication de code, ne laissant ainsi que très peu de place pour Lift lui même.

Nous consacrerons donc un retour à Scala en deux parties : la première sur les acteurs (présent billet) et la seconde sur ScalaTest.

La présentation démarre tambour battant avec un schéma sur The evil of global state et, dans le cas du partage de variables entre plusieurs threads, l’incontournable :

int currentSpeed  = 0;
synchronized (currentSpeed) {...}

Tous les threads peuvent accéder à cette variable, il faut donc la synchroniser.

Le passage de messages est tout de suite introduit avec le même exemple : une vitesse et 2 threads/acteurs qui souhaitent accéder à cette variable. Mais cette fois-ci, pas de variable synchronisée mais un acteur SpeedSensor qui porte la valeur, un acteur CruiseControl qui récupère le message et exécute les actions adéquates, en l’occurrence appeler un autre acteur qui fera un ajustement de la vitesse. On se retrouve avec un exemple où tous les threads partagent la même donnée currentSpeed mais grâce à la programmation par message, il n’y a plus besoin synchroniser cette variable.

Les idées véhiculées par les acteurs peuvent alors se résumer par :

• Favoriser l’immutabilité des messages.
• Gérer une pile de messages (Mailbox).
• Gérer différentes actions selon le message entrant.

Tous ces points énumérés nous font rapidement tilt dans la tête et l’on pense évidemment au langage Scala qui porte tout à fait ces valeurs. Pour rappel, Scala est un langage qui :

• Favorise l’immutabilité des objets.
• Est orienté objet + orienté fonction.
• Promeut le pattern matching (un switch sous stéroïdes selon le speaker qui permet différentes actions selon le type de pattern correspondant).
• Permet le DSL (écriture plus lisible d’API).
• Tourne sur une JVM donc intégralement compatible Java.

Il ne faut pas oublier qu’en outre les acteurs ne sont pas intégrés au langage Scala, ce n’est qu’une API qui est fournie avec Scala. L’écriture des appels fait croire à de la syntaxe propre au langage mais ce n’est qu’un DSL qui invoque de simples méthodes. ScalaTest vous montrera (d’ici quelques jours) la puissance de ces DSLs et de ce qu’il est possible de faire avec. D’ailleurs, si l’implémentation des acteurs ne vous plaît pas, vous pouvez tout à fait les refaire à votre façon (et à vos risques et périls )

La déclaration d’un acteur en Scala se fait en étendant le trait Actor et en redéfinissant la méthode def act() . La définition des messages peut se faire par case class ce qui permet de voir rapidement tous les types de messages disponibles pour nos acteurs et ainsi effectuer un pattern matching lisible :

case class Subscribe(user : User)
case class Unsubscribe(user: User)
...
msg match {
   case Subscribe(user) => println(user + "subscribed")
   case Unsubscribe(user) => println(user + "unsubscribed")
}

L’envoi de message se fait de différentes manières :

• Asynchrone : chatRoom ! Subscribe(User("Foo")), non bloquant, retour immédiat.
• Synchrone : var result = chatRoom !? Subscribe(User("Bar")), bloquant, en attente du retour de la méthode.
• Future : var future = chatRoom !! Subscribe(User("Baz")), non bloquant, en attente du retour de la méthode.

Vient ensuite la partie haute performance des acteurs. Franck nous présente ainsi les Remote actors ou acteurs distribués. Ces acteurs ont la particularité de dialoguer entre eux même s’ils sont sur différentes machines physiques. La création d’un acteur remote se fait grâce à l’appel à alive (qui crée une socket et la bind sur le port spécifié) et à register :

alive(9090)
register('chatRoom', self)

L’envoi de message se fait en récupérant un proxy sur le nœud courant, l’appel à select permettra de récupérer l’acteur dont l’alias a été enregistré par le register (voir ci-dessus). L’acteur remote aura la bonne référence au niveau du sender (référence à celui qui a envoyé le message) :

val remoteActor = select(Node(<address>, 9090), 'chatRoom')
remote ! Post("Foo=Bar")

La partie scalabilité approche à grand pas et le speaker évoque à présent les deux manières de démarrer nos acteurs :

• Soit un thread par acteur : grosse consommation mémoire et très vite limité par la JVM (plusieurs milliers).
• soit event-driven : découplage des acteurs et des threads jvm, exécuté sur un thread pool, attente du message sans consommer de thread ! On parle ici en millions d’acteurs !

Vous trouverez un exemple d’actors in action fourni par le speaker à cette url ainsi qu’un très bon article sur les acteurs remote.

Nous avons déjà publié plusieurs articles sur Hibernate Search : de l’introduction qui se focalisera sur l’architecture de l’outil au Hands On qui vous permettra de mettre les mains dedans. Les différentes recherches Full Text disponibles (appoximation, phonétique…) ont aussi été résumées dans le compte-rendu de la présentation de l’outil à Jazoon.

Le speaker insistera surtout sur la convention over configuration une approche programmatique du produit. Après l’énumération des annotations possibles (@Indexed, @Field, @FieldBridge, @IndexedEmbededd, @Boost et @Analyzer), les premières questions sur la configuration par XML tombent et la réponse est assez direct : Because we hate XML

Il enchaîne ensuite avec quelques slides d’architecture. On retiendra ainsi que Hibernate Search est construit sur Hibernate Core, que le produit est Event Based et que l’indexation manuelle massive est optimisée. Un slide nous montrera les différentes étapes d’une recherche avec Hibernate Search, tout d’abord un appel à Lucène pour récupérer nos documents et, si besoin, un appel au cache ou à la base de données pour récupérer les entités souhaitées.

Emmanuel terminera avec une Road Map plutôt chargée dont :

• Amélioration des performances de l’API programmatique.
• Indexation massive multi-threadée.
• Clustering (travail en collaboration avec Infinispan).
• Meilleure intégration avec Solr.
• Amélioration des Query (construction simplifiée…).
• Statistiques.

Pas de date de sortie prévue pour cette nouvelle version mais il est toujours possible de jouer avec Hibernate Search 3.1.1 GA (version actuelle du produit qui date de 6 mois) et de mettre en œuvre quelques recherches Full Text !

Le projet

Tout d’abord, la home page du projet Swag Swap se trouve à cette url. Elle regroupe toutes les informations utiles, les liens vers les différents projets par technos, un espace google-moderator pour poser des questions aux speakers (et réponses en live).

Fonctionnellement, le projet est un espace de vente d’objets divers et variés avec notation de ces objets, commentaires associés, etc. Côté administration, on pourra gérer les objets (ajouter, modifier ou supprimer) et avoir accès à d’autres fonctionnalités. On illustre ainsi GAE par un projet plus concret que le basique Helloworld. A gauche l’apparence de l’application GWT (single page interface) et à droite celle des applications Spring MVC et JSF 2.0 :

Fondamentaux

Avant de rentrer dans le vif du sujet, quelques rappels sur l’architecture de GAE nous sont faits. Ainsi, GAE est de type PaaS : aucune installation hardware ni d’infrastructure mainframe, tout est géré par Google qui hébergera notre application sur ses serveurs et la dimensionnera à l’infini si besoin (attention aux quotas ). La base de données utilisée est BigTable, base de données non relationnelle distribuée, scalable, transactionnelle et schema-less ; le tout accessible par les APIs JDO et JPA.

Les détails techniques sont tout de suite évoqués avec entre autres :

• des requêtes limitées à 30 secondes,
• pas de serveur push,
• pas de threads,
• un système de fichiers en lecture seule,
• des whitelisted classes (plusieurs classes du JDK non disponibles sous GAE),
• impossibilité de créer/mettre à jour plus d’une entité au sein d’une transaction.

Ces quelques lignes peuvent évidemment faire reculer violemment un développeur Java et c’est bien là l’idée de cette conférence : n’ayez pas peur ! La preuve : leurs applications fonctionnant sous GAE et sous 3 frameworks web différents ! Quelques adaptations sont néanmoins nécessaires.

Pour ceux qui souhaitent approfondir la persistance dans GAE,je vous renvois vers un précédent article qui traite parfaitement le sujet.

Implémentations

Côté architecture, on retrouve globalement ce que l’on connait déjà dans notre écosystème JEE à savoir :

• Spring 3.0,
• JDO,
• Une couche service partagée par toutes les applications,
• RESTful,
• Spring MVC / JSF 2.0 / GWT 1.7,
• Build, tests et déploiement avec Ant,
• Pour le debug, l’appengine development server pour SMVC et JSF et le Hosted Mode pour GWT,
• Gestion des projets avec google-code (issues, version control, release management).

Nous sommes donc en face d’une application 3-tiers standard. Les POJOs sont de simples POJO Spring. La couche DAO utilise un JdoTransactionManager mappé avec un PersistentManagerFactory connecté sur le datastore d’appengine (org.datanucleus.store.appengine.jdo.DatastoreJDOPersistenceManagerFactory).

La première chose qui saute aux yeux est bien sûr l’utilisation de JDO. Pourquoi ce choix (question du modérateur) ? Parce que la majorité des tutoriels s’appuie sur JDO. Il est tout à fait possible d’en trouver avec JPA mais ils sont globalement moins nombreux. D’où le choix de JDO. Avec toutes ces présentations Devoxx autour de JPA 2, cela surprend…

Nous nous retrouvons ensuite rapidement dans Eclipse avec de nombreux exemples de codes, d’injections, de configuration… La conférence prend rapidement un air de présentation de Spring MVC avec la configuration par annotations et entre autres les URI Templates de RESTful Spring MVC 3. Pour les habitués de Jersey, l’idée est la même (paramètres dans le path de l’URL) mais le nom des annotations change un peu. Voici un exemple d’utilisation :

@RequestMapping(value="/edit/{id}", method=RequestMethod.GET)
public String editHandler(@PathVariable("key") Long key, Model model) {
  SwagItem swagItem = itemService.get(key, true);
}

Suivront ensuite quelques screenshots de l’utilisation de MemCache et d’envoi de mails avec Task Queue, la gestion de transactions, la gestion d’Entity Groups… Le tout est bien sûr testé unitairement. Nous passerons sur ces points, de nombreuses documentations existent un peu partout sur la toile.

Le tour complet est fait, mais maintenant on veut savoir…

Problèmes rencontrés

Bon alors, quels sont les problèmes que vous avez rencontrés ?

Et bien il y en aura eu, du simple à résoudre au plus complexe qui demande de bien écrire ses APIs ou de paramétrer légèrement sa configuration.

Côté back-end, la mise à jour d’une seule entité au sein d’une transaction peut évidemment poser de gros problèmes concernant l’insertion de nombreuses entités mais aussi concernant un rollback de transaction. Pas de réelle solution, à part programmer à la main un rollback sur des objets déjà commités.
Concernant l’impossibilité d’écrire sur le disque, la base de données contient un champs BLOB qui contiendra les images des articles à vendre.

Spring MVC a posé des soucis concernant quelques requêtes Ajax et surtout celles de rating qui requièrent un utilisateur logué. Dans ce cas, la page de connexion spéciale Google (au passage non configurable) apparaît et, une fois logué, la redirection se fait sans les paramètres d’URL. On perd donc le fait que l’on venait de voter pour un article ; nous avons donc cliqué dans le vide juste pour nous connecter.

Les gros problèmes concernant le frontend se sont plus focalisés sur JSF 2.0 (le pauvre…) avec quelques hacks autour de la classe WebConfiguration. Un problème s’est aussi posé concernant le state saving de JSF 2.0 côté serveur. Les scopes doivent être réduits à request et à view, le state doit être sérialisé dans le view scope et (enfin et non des moindre) RichFaces et ICEFaces ne peuvent pas être utilisés (whitelisted classes). Beaucoup de ralentisseurs donc mais qui n’ont pas empêché l’application d’être disponible et fonctionnelle à Devoxx.

Pour GWT, beaucoup de temps a aussi été investi pour brancher les services remotes sur Spring convenablement (avec P.G Taboada’s AutoinjectingRemoteServiceServlet). Les problèmes majeurs rencontrés dans le développement de l’application GWT se situent au niveau de son protocole GWT-RPC et de l’impossibilité de sérialiser des types Text et Blob de BigTable. Gilead (anciennement Hibernate4GWT) aurait pu aider dans la gestion de ce mapping mais cela n’a pas fonctionné. La solution de contournement a donc été de créer des DTOs pour tous les spring beans ! De plus, ces DTOs, spécifiques à l’application ne sont pas compatible avec les tableaux SmartGWT. Il a donc fallu les copier dans les records SmartGWT… Tout fonctionne mais avec beaucoup de beans passe-plats, le tout n’étant pas très automatique.

Conclusion

Au final, l’application Spring MVC, couche service incluse, n’aura pris que 3 jours à être codée. Alors que pour JSF 2.0 et GWT 1.7, on est plutôt sur 2 semaines chacun et uniquement pour la partie frontend (couche service partagée). La rapidité d’écriture est donc clairement à l’avantage de Spring MVC (pour cette application). JSF 2.0 a été très retardé par ses incompatibilités avec GAE alors que GWT aura péché par sa difficulté d’intégration avec Spring, les problèmes liés aux échanges RPC et Gilead qui n’a pas fonctionné.

Que peut-on réellement en tirer ? Premièrement les 3 frameworks, même si ce fût dur, fonctionnement correctement sur GAE, si on fait abstraction des quelques Errors qui apparaissaient de temps à autre sur le grand écran. On pourra mettre ça sur le dos du wifi de Devoxx qui ne monte pas très bien en charge .

Parmi les liens utiles, on notera la recherche sur google de « Will it work on app engine » qui donne en premier résultat un site listant de manière assez complète les librairies et leur compatibilité sur GAE : http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine mais aussi le GAE Bar http://aralbalkan.com/1784.

Car oui : JSF 2.0 annonce la couleur et souhaite faire participer la communauté. Dans cet esprit, les speakers nous présentent le topic twitter #jsf2next pour partager autour des évolutions futures de JSF, souhaitées ou non. Ils enchaînent ensuite avec un trombinoscope de toutes les personnes qui se trouvent derrière JSF 2.0 (on reconnaîtra quelques visages au passage) :

L’aspect communautaire sera rappelé tout au long de la session et on sent vraiment que JSF met le paquet pour être apprécié des développeurs. Les speakers insisteront beaucoup sur le tag JSF2.next avec des slides spécifiques pour donner quelques idées internes ou remontées par la communauté pour (déjà) améliorer JSF 2.0.

La présentation fût découpée en 3 parties : Vue, Contrôleur et Modèle (approximativement 1h pour chaque partie), ce qui nous donne ainsi un bon aperçu de tous les changements de chaque couche du MVC. Une session de BOF spéciale JSF 2.0, qui a eu lieu le soir même, apportera quelques précisions sur certaines fonctionnalités non évoquées lors de la conférence.

Vue

Premier rappel côté Vue et déjà quelques tacles à la gorge : JSP avec ses points faibles (dont certains sont assez discutables…) :

• la complexité de développer une librairie,
• l’état stateful des tags qui impose de faire des appels à release sur les objets tags pour les réinitialiser,
• l’obligation d’une phase de compilation lors du premier affichage,
• le mélange de la présentation avec la couche métier
• le fait que JSP soit orienté contenu (et non composant).

Facelets arrive ainsi avec ses XHTML tags, stateless par défaut, des librairies plus simples à développer, du templating et plus de compilation Java. Et, première bonne nouvelle pour les fans de Facelets, la librairie est incluse dans la spécification avec les mêmes fonctionnalités et quelques améliorations. Elle inclura aussi Gracelets (Groovy pour JSF / Facelets).
La présentation se focalise ensuite sur un des points noirs de JSF : la création de composant… Vous savez, les composants pour lesquels il faut coder un UIComponent, un Renderer, tag/tld, le (ugly) faces-config.xml…

La création de composants est simplifiée dans JSF 2.0 : soit en utilisant les annotations et le fichier taglibs.xml (configuration ainsi simplifiée) soit les Composite Components, une des grosses nouveautés de cette version. Nous avons ainsi les tags composite:interface et composite:implementation pour définir le composite et l’implémentation.

Ces composites sont accessibles directement dans la webapp ou dans un JAR, avec la possibilité d’ajouter des listeners et converters, de plugger un resource bundle…

L’Ajax n’est pas en reste avec un composant embarqué dans JSF 2.0 : jsf.ajax.request(), utilisable par le tag <f:ajax> qui peut-être soit nested soit wrapping.

Contrôleur

Comme la plupart des frameworks web du moment (Wicket pour ne citer que lui), JSF 2.0 pourra enfin se targuer de supporter… GET (pas de sarcasme svp ) ! La conséquence directe est que nous allons enfin pouvoir bookmarker nos URLs. Un exemple avant/après :

<h:link outcome="product" value="View">
    <f:param name="id" value="#{product.id}" />
</h:link>
// qui donnera :
<a href="/product.jsf ?id=3">View</a>

Côté événement, le nouveau SystemEvent fonctionne en mode publish/subscribe avec des événements de type PostAddToViewEvent (après la création du composant) et PreRenderViewEvent (avant le rendering du composant).

Une autre partie intéressante est la gestion des ressources dans l’application avec 2 possibilités de récupération selon que la ressource soit présente dans un dossier de la webapp ou dans un JAR :

// Web root
<h:graphicImage name="hello.png" />
// Classpath of myimages.jar
<h:graphicImage name="hello.png" library="myimages" />
<h:graphicImage value="#{resources['myimages:hello.png']}" />

Modèle

Pour la partie modèle, ce sera surtout une présentation des différentes technologies JEE 6 avec leur intégration dans JSF 2.0 : Managed Beans (partie de JSR-316), Contexts and Dependency Injection (JSR-299), Bean-Validation (JSR-303) et JAX-RS (JSR-311).

Outre les fameuses annotations @Inject (CDI) et @Named (EL), la présentation fera la part belle à Bean-Validation avec l’ajout d’une annotation au niveau de notre POJO qui validera côté Data, Business mais surtout, ce qui nous intéresse, Client.

On se retrouve donc avec les exemples suivants qui sont nativement gérés par JSF 2.0 dans nos pages JSF :

public class User {
   ...
   @NotNull @Size(min=3, max=25)
   public String getUsername() {return username;}
   @NotNull @Email
   public String getEmail() {return email;}
}

Il sera toutefois possible, côté JSF, de désactiver certaines validations, soit par paquet soit au cas par cas.

A noter une bonne gestion du null dans un champ (null ou String vide) avec la possibilité de valider ou non le champ si une annotation Bean-Validation est présente ou si le context-param suivant est présent :

<context-param>
   <param-name>javax.faces.VALIDATE_EMPTY_FIELDS</param-name>
   <param-value>true</param- value >
</context-param>

Mais, il est aussi possible de forcer le champ vide à null avec le paramètre assez explicite suivant :

<context-param>
   <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
   <param-value>true</param- value >
</context-param>

Dernier point abordé, la validation multiple avec plusieurs approches :

• Avant la construction du modèle avec un test de tous les champs sur un événement PostValidateEvent ;
• Après la construction du modèle avec Bean-Validation (mais un objet a déjà été construit… à vous de vous faire votre idée).

BOF

Au niveau des sujets esquivés en conférence, quid d’un projet comme Spring Web Flow pour la gestion d’un flow de page qui est supporté par Seam mais pas par JSF ? Une des réponses est que le projet est plutôt complexe et mériterait peut-être une spécification plus globale pour définir ce qu’est un flow de page, les événements autour de ce flow… Il n’en reste pas moins que JSF 2.0 supporte parfaitement le mode Stateless mais pour l’instant le Stateful ne l’est pas…

Au niveau des tags ajax embarqués, il devrait être assez simple de brancher un jQuery ou un Script.aculo.us sur JSF 2.0 et profiter d’une expérience Ajax complète. Reste à voir l’intégration avec des Composite Components.

Conclusion

Une présentation très rythmée avec beaucoup de slides (peut-être trop) qui ne laissent donc que très peu de temps pour la prise de note. Dommage car certains sujets, non évoqués dans cet article, auraient aussi mérité leur place. Mais ce n’est que partie remise pour un prochain article !

En tout cas, force est de constater que JSF 2.0 tend vraiment à une simplification d’utilisation, orienté annotation et zero-XML. Des Composite Component simples à écrire, une intégration gracieuse avec Bean-Validation… en bref, beaucoup de bons points !

Après un petit café revigorant, voici déjà venir les premières sessions de l’édition 2009 de Devoxx et, le sujet de cet article, Kanban in action par Olav Maassen.

Après un petit rappel sur les origines du mot (qui en kanji signifie kan=visuel et ban=tableau, carte, fiche), le deuxième slide donne le ton de cette conférence qui sera interactive (plusieurs travaux pratiques sur les 3h) avec une première question : donnez quelques exemples quotidiens de système Kanban. Plusieurs réponses affluent dont :

• le parking avec un flux de voitures entrantes bloqué si toutes places du parking sont pleines ;
• la toilette des enfants avec une baignoire qui ne contient qu’un enfant à la fois (dès qu’un enfant a terminé, l’autre prend sa place) ;
• le speaker retiendra Mac Donalds (et oui) avec la gestion du stock de burger disponible : une pancarte métallique qui, une fois déplacée au dessus des rails de burgers vides, signifie qu’un burger n’est plus disponible, il faut alors en produire.

Ces exemples tournent autour de 2 principes : la capacity constraint (par exemple une autoroute, toujours disponible mais dépendante du flux) et la non-instant availability (par exemple un ferry qui une fois en mer n’est plus disponible). Un des principes du Kanban est de rendre certaines choses visuelles : voir l’indisponibilité de hamburgers marqués par un token en est un bon exemple.

Les freins

La présentation se focalise ensuite sur les mauvaises pratiques de nos projets d’entreprise faisant que Kanban sera difficile à mettre en place.

Les projets avec deadline (surtout quand celle-ci se rapproche) ont fait débat dans la salle. Pour les conférenciers, les mauvais choix qui peuvent être faits par l’entreprise sont : le report du projet, engager plus de personnes ou faire beaucoup d’overtime Et quel que soit le cas, des choix malheureux risquent d’être faits : ne plus rédiger les spécifications, réduire voire supprimer les tests unitaires, privilégier la vitesse de production à la qualité du code (tout ceci dans un but de gain de temps) ! Vous l’aurez compris, et ce n’est pas forcément spécifique à Kanban, nous sommes ici en présence de mauvaises pratiques reconnues et difficilement récupérables par la suite.

Pour rester dans les mauvaises pratiques, Olav nous propose un TP, comment construire ou détruire la confiance dans une équipe. Cacher de l’information, manquer de confiance en l’équipe, ne pas donner de responsabilité à l’équipe… La destruction est assez facile à illustrer, la construction ressortira surtout de l’implication de l’équipe dans le projet et les décisions.

Une petite comparaison orale (pas de trace !) avec Scrum ou Lean nous permet de constater qu’il n’y a pas de planning poker ou de session d’estimation. En effet, cela ne représente pas une valeur fonctionnelle métier pour le client (<troll>c’est du temps perdu !</troll>). Au niveau des réunions, et plus particulièrement le stand-up meeting, les 3 questions habituelles de Scrum sont remplacées par un bref regard global sur le tableau afin de voir si tout se passe bien. En général, voir s’accumuler des post-it dans une colonne n’est pas bon signe et c’est ici que l’équipe intervient et que le stand-up devient plus animé.

Kanban à la rescousse !

Le décor est planté, la salle a les idées claires sur ce qui va, ne va pas ou peut encore être amélioré sur nos projets, il est grand temps de présenter formellement le sauveur Kanban (avec au passage un bon article de présentation sur InfoQ). Kanban insiste sur plusieurs points :

• la qualité,
• réduire le work in progress, livrer le plus possible,
• équilibrer demande / livraison,
• prioriser,
• réduire les variables et améliorer les processus.

Les étapes de mise en place sont résumées ainsi :

• s’accorder sur les objectifs,
• définir la value stream mapping (analyse des flux de besoins),
• définir des inputs de contrôle,
• définir le done,
• définir un set de tâches de travail,
• rencontrer les parties prenantes du projet (amont et aval),
• créer votre tableau Kanban (Kanban board) qu’il soit physique ou électronique (idéal pour les équipes distribuées).

A cela, il est possible d’ajouter différentes métriques telles que le Work In Progress, la qualité de code, la durée moyenne des tâches, le temps perdu (obstacles, bugs, manque d’information…).

Tout comme Scrum, Kanban arrive avec plusieurs bonnes pratiques mais ne pourra pas résoudre certaines lacunes comme un manque total de communication dans l’équipe, ou une organisation qui freine les changements… Dans un souci d’amélioration continue, Kanban propose plusieurs étapes afin de résoudre les fameux bottleneck du Lean (trouver la contrainte, définir une résolution possible, appliquer, trouver la contrainte suivante).

Conclusion

Tout ceci (qui ressortira plusieurs fois durant la présentation) a pour but d’obtenir les effets positifs suivants : confiance (Trust), travail d’équipe (Teamplay), transparence (Transparency).

Plusieurs questions sur la difficulté de mise en place de Kanban sont posées lors du Q&A de fin de session. Le speaker insiste sur le fait qu’en effet cela n’est pas trivial, mais les gains sur le long terme sont plus qu’avantageux.

Quelques liens pour approfondir ce sujet:

• http://www.agilemanagement.net
• http://www.channelkanban.com
• http://www.limitedwipsociety.org

Tout s’est toujours bien passé jusqu’au moment où nous avons attaqué concrètement la partie cliente (avec ses feuilles de style, fichiers Javascript…). En effet, le problème survient lors de la modification à la volée de ces fichiers pour n’avoir qu’un rafraîchissement à effectuer dans notre navigateur (et pas un arrêt/relance du serveur).

Ainsi, à la sauvegarde, on obtient l’erreur suivante :

Il nous est alors impossible de sauvegarder le fichier, l’erreur fichier ayant une section mappée utilisateur ouverte apparaît.

En effet, le file locking, mécanisme de restriction d’accès aux fichiers par les utilisateurs / processus, pose problème sous Windows si l’on veut modifier ces fichiers.

Jetty monte en mémoire tous les fichiers statiques (html, css, js, …) et utilise pour cela une section mappée (memory mapped file) dans le cas d’un connecteur NIO (celui par défaut). Or, sous Windows, l’utilisation de ce segment de mémoire virtuelle provoque immédiatement un lock du fichier. Il devient donc impossible de modifier dynamiquement ces fichiers et nous sommes obligés de redémarrer notre Jetty pour prendre en compte toute modification.

Pour contourner ce problème, plusieurs solutions existent.

Changement de connecteur (NIO vers IO)

La plus simple et rapide est de modifier le connecteur par défaut (SelectChannelConnector) qui est de type NIO(contournement du problème mais après tout nous sommes en dev, pas besoin d’en faire des tonnes ).

Donc, dans notre pom.xml, nous allons modifier la configuration de notre maven-jetty-plugin en ajouter les quelques lignes suivantes :

<plugin>
   <groupId>org.mortbay.jetty</groupId>
   <artifactId>maven-jetty-plugin</artifactId>
   <configuration>
      ...
      <connectors>
         <connector implementation="org.mortbay.jetty.bio.SocketConnector">
            ...
         </connector>
      <connectors>
      ...
   </configuration>
</plugin>

Le contournement se situe au niveau de la balise connectors. Ainsi, on force Jetty à utiliser le SocketConnector au lieu du SelectChannelConnector par défaut. Ce connecteur non NIO n’utilisera pas de section mappée pour charger les fichiers statiques et pourra dès lors les modifier à notre guise sans redémarrer Jetty.

Webdefault.xml

L’autre solution, que l’on pourrait qualifier de plus officielle (car directement sur le site de codehaus) nous plonge dans le Jar pour modifier la configuration du fichier webdefault.xml (fichier chargé par Jetty avant le web.xml).

Ce fichier se trouve dans le Jar de Jetty (%M2_REPO%/org/mortbay/jetty/jetty/6.1.x/jetty-6.1.x.jar), au niveau du package org.mortbay.jetty.webapp. Il faut alors trouver la balise servlet où l’on peut lire

<!—
...
useFileMappedBuffer : If set to true (the default), a  memory mappedfile buffer
will be used to serve static content when using an NIO connector.
Setting this value to false means that a direct buffer will be used instead.
If you are having trouble with Windows file locking, set this to false.
...
-->

Cela tombe très bien, c’est exactement notre problème . Nous pouvons donc passer cette valeur à false dans le fichier webdefault.xml pour ne pas utiliser cette fonctionnalité :

<servlet>
   ...
   <init-param>
      <param-name>useFileMappedBuffer</param-name>
      <param-value>false</param-value>
   </init-param>
   ...
</servlet>

Il ne reste plus qu’une dernière manipulation : dire au maven-jetty-plugin d’utiliser notre fichier de configuration webdefault.xml. Ces quelques lignes feront ce travail (avec votre fichier au niveau de src/main/etc) :

<plugin>
   <groupId>org.mortbay.jetty</groupId>
   <artifactId>maven-jetty-plugin</artifactId>
   <configuration>
      ...
      <webDefaultXml>src/main/etc/webdefault.xml</webDefaultXml>
      ...
   </configuration>
</plugin>

Voilà donc un gain de productivité qui ne se refuse pas !

Évolutions du langage

Petit rappel : la toute première version de GWT (1.0) est sortie le 17 mai 2006. Oui, il y a seulement 2 ans et demi ! De nombreuses versions se sont suivies pour arriver à une version 1.4 (fin août 2007) stable et très complète, permettant de démarrer sereinement nos projets.
Mais voilà, fin août 2008 (1 an plus tard, la plus longue période entre 2 releases), la communauté GWT était en ébullition : en effet, l’importante version 1.5 pointa son nez apportant un lot de nouveautés assez importantes.
De nombreux articles nous exposent parfaitement ces nouveautés du langage ; on pourra se diriger sur le Blog de GWT, sur InfoQ ou chez Octo.
Un rapide résumé donnerait :

1. Enfin du Java en version 5 : annotations, generics, enhanced loop, autoboxing, import static…
2. Generics ? Donc nos @gwt.typeArgs sont terminés !
3. JRE Emulation beaucoup plus large avec entre autres les très attendues TreeMap, LinkedHashMap et autres StringBuilder
4. Compilateur beaucoup plus rapide
5. Widgets plus complets et plus rapides

En bref : que du bon !

Plug-ins

GWT Designer

Plugin de type WYSIWYG. Il permet entre autres :

• la création de projet GWT, de module, de service et de librairie,
• génération du service Async ,
• la palette de widgets (intégrée dans une vue multi-onglets Design et Source),
• ajout d’événements et modification des propriétés d’un composant dans les onglets Event et Properties,
• Compilateur et Hosted Mode intégrés au projet (Builder Eclipse, menu « Run As… »),
• drag and drop côté Design qui met automatiquement le « Source » à jour.

À noter qu’il faudra, au-delà de la période d’essai, une licence annuelle ou perpétuelle pour continuer à l’utiliser.

VistaFei

Environnement de développement (qui s’appuie sur Eclipse 3.2) intégrant toute sorte de plugins spécialement conçus pour GWT. Il propose :

• la création de projet, de module (GWTView) et de service,
• un WYSIWYG (très similaire à celui de GWT Designer) séparant l’onglet « Properties » de la vue « Design »,
• la génération de code depuis la « GWTView »,
• l’internationalisation aussi générée.

Son utilisation est gratuite avec la licence « Community Edition ».

IntelliJ IDEA

Un plugin GWT intégré à l’IDE très abouti :

• création de projet, de module et de service,
• compilateur de projet,
• complétion Javascript dans une méthode native (non, vous ne rêvez pas !!!),
• quick-fix spécifiques GWT (votre code Java est correct mais il ne compilera pas, oubli de l’interface « IsSerializable », utilisation d’une librairie non émulée…), remplacement des @gwt.typeArgs…,
• navigation rapide entre les méthodes synchrones et asynchrones.

Le plugin est intégré à l’IDE de JetBrains, il faudra donc mettre la main à la poche pour obtenir une licence à moins de vous lancer dans un projet Open Source.

Cypal Studio

Le plugin que tout développeur GWT anti-WYSIWYG a dans son IDE !

• création de module, de service et d’exemple (sample),
• compilateur intégré au projet (« builder » Eclipse),
• lancement du Hosted Mode.

Simple mais efficace, ce produit est disponible gratuitement.

Frameworks

GWT-Maven

De nombreuses commandes maven adaptées à GWT sont disponibles, on notera parmi les plus intéressantes :

• Lancement du Hosted Mode (Tomcat, noserver, debug…),
• Compilation GWT,
• Lancement des tests unitaires GWT,
• Génération des interfaces pour l’internationalisation,
• Création de WAR GWT,
• Création de JAR GWT.

Gilead (anciennement Hibernate4GWT)

L’un des gros problèmes rencontrés au démarrage de GWT est l’utilisation des POJOs Hibernate côté client.
Je vous renvoie vers le très bon article d’Amin Fathallah (Xebia) qui détaille très bien les problèmes rencontrés.
Ainsi, Gilead nous permet d’utiliser nos POJOs Hibernate directement côté client sans aucun mapping Dozer !

Spring

Accessible par les librairies GWT-SL et GWT-WL, il est tout à fait possible d’utiliser Spring dans un projet GWT.
Le principal changement est que les services ne sont plus définis en tant que servlets dans le web.xml. Ils sont remplacés par la classe DispatcherServlet de Spring qui pilotera l’application.
On notera aussi les classes GWTController et GWTHandler, cœur de GWT-SL, permettant de wrapper intégralement nos actions et nos services.

G4JSF

L’adaptation de JSF dans le monde GWT. Même mécanisme que pour le SpringController i.e. que l’on aura des interfaces/classes à implémenter/étendre au lieu des classes GWT standard, les principales étant ComponentEntryPoint et GwtFacesServiceAsync.
Le tutoriel de référence pour l’intégration de JSF avec GWT se trouve sur The Server Side.

APIs graphiques

Le tour d’horizon continue avec les APIs graphiques.
Chaque composant ne sera pas détaillé à outrance, seuls certains seront cités pour donner un aperçu général de ce qui est proposé (détail complet sur les sites officiels respectifs de chaque librairie).

Widgets Core (démo)

Premier réflexe avec tout ce que l’on entend sur GWT : foncer sur la première librairie de composants graphiques à la mode !
Mais n’oublions pas toutefois que GWT propose en standard des widgets haut niveau très complets :

• Boutons : basique, checkbox, radio, custom…,
• Listes : basique, suggest, arbre, menu…,
• Text : basique et riche (à la word),
• Popups,
• Panels : décorateur, horizontal, vertical, dock, disclosure, onglet…,
• Tables : tableau standard et flex.

GWT-Ext (démo)

Certainement la librairie graphique la plus répandue.
Wrapping complet de l’API ExtJS dans sa version 2.0.2.
L’API ne contient donc quasiment que des classes dont les méthodes font une redirection native vers le code Javascript d’ExtJS.
On retrouvera donc tout ce qui se fait dans ExtJS avec des composants très puissants comme :

• Arbres : éditable, drag & drop (arbre vers arbre ou tableau), tri, checkbox…,
• Layouts : horizontal, vertical, accordéon…,
• Liste : basique, listes liées, live (suggest), paginé…,
• Tableau : éditable, tableaux groupés, JSON ou XML, chargement local ou distant, checkbox…,
• Formulaire : à onglets, fieldset, multi-colonnes, binding avec un tableau…,
• Éléments redimensionnables, déplaçables…
• Widgets bien stylés et des thèmes out-of-the-box

Le point noir reste toutefois la Javadoc, même si celle-ci s’étoffe au fur et à mesure des sorties de GWT-Ext (gros efforts fournis entre les versions 2.0.2 et 2.0.5). Elle reste cependant insuffisante. On pourra tout de même se retourner sur la doc d’ExtJS (puisque ce n’est que du pur wrapping) mais dès que l’on souhaitera aller un peu plus loin avec les composants, il faudra mettre les mains dans le cambouis Javascript.

Ext-GWT (démo)

Le produit de la compagnie ExtJS adapté à GWT.
Ext-GWT prend le parti de tout réécrire en pur GWT i.e. il n’y a aucun Javascript externe, tout est en Java.
Autre atout, l’API utilise les mécanismes internes de GWT permettant une intégration standard des fonctionnalités comme le remote service en Callback, retour JSON, XML… mais aussi du Java 5 (generics, enums et varargs).
On retrouve, sans surprise, les mêmes composants que pour GWT-Ext.
A noter enfin 3 licences disponibles pour le produit (commercial, open source ou revendeur).

Smart-GWT (démo)

Sanjiv Jivan a encore frappé !
Après son wrapping complet d’ExtJS avec GWT-Ext, il s’attaque cette fois-ci à la librairie SmartClient avec sa nouvelle API SmartGWT (nous vous en parlions dans une précédente revue de presse).
Le wrapping est encore une fois très complet : tous les composants de SmartClient sont présents dont :

• Arbre : colonne bloquée, drag & drop entre de nombreux composants, data binding multiples…,
• Slider, effects, animations, dialogs, look & feel, …
• Tableau : filtres, interactions avancées, …
• Tile (démo),
• Liste-Tableau, Calendrier (à la outlook), load on demand, …

On retrouvera aussi, et sans surprise, la plupart des composants combobox, radio, field, … d’autres librairie du même type.

Rialto-GWT (démo)

De même que pour Ext-GWT, Rialto-GWT dans sa version 2.0 nous propose d’utiliser GWT 1.5 donc Java 5.
L’API utilise aussi les mécanismes internes à GWT, le Wrapping Javascript est présent mais l’abstraction avec les classes Java rend l’utilisation très simple.
A noter toutefois une Javadoc de composants peu fournie…
Les composants principaux sont proches de ceux d’Ext-GWT.

Tatami (Dojo) (démo)

Encore une célèbre librairie Javascript porté en GWT : Dojo !
Une fois de plus, on retrouve le support de GWT 1.5, des tableaux en tout genre, des sliders, des pickers…

Autres…

D’autres librairies/codes sont disponibles sur la plupart des sites d’informations GWT, on trouvera ainsi quelques wrapper Script.aculo.us (ici ou là) mais aussi des wrapper jQuery (avec entre autre GQuery).

APIs générales

I18N

GWT gère nativement l’internationalisation, donc pas de librairies externes pour cette fonctionnalité.
L’utilisation est simple :

• un fichier properties contenant toutes nos clés,
• des interfaces (I18NConstants, I18NMessages…) Java permettant de faire appel à ces clés,
• une entrée dans notre module.gwt.xml avec si besoin la locale par défaut,
• une locale pouvant être définie au runtime, dans la JSP ou dans l’URL.

Logs (demo)

Un logger côté client très complet avec différents niveaux de logs : info, warn, debug, error et fatal.
De nombreux loggers sont disponibles comme le ConsoleLogger, le GWTLogger ou bien encore le FireBugLogger.

Google API

Gears, gadgets, Ajax Search et Maps, voici ce que propose la librairie de Google.
À noter que Visualization est en release candidate.

Maths

Émulation de BigInteger et BigDecimal avec un grand nombre de méthodes (add, subtract, multiply, divide, abs, negate, compareTo, equals, toString…).

Et bien d’autres encore !

A chercher/récupérer au besoin

On pourra rapidement citer GWTEventService (qui permet entre autre de faire du pushing / comet), PureMVC (MVC pour GWT) ou bien encore Goda-Time (Joda-Time pour GWT !).

Conclusion

Ce petit tour d’horizon de la galaxie GWT nous permet de retenir 3 choses : vous avez dit galaxie ?, [Mode gros doutes] Tu penses que c’est possible ? et enfin ça ressemble vraiment à un puzzle cette techno….

Galaxie ? On peut se poser la question dans le sens où, si l’on creuse un peu, on trouve en effet quelques APIs très bien faites… mais elles sont tout de même rares ! Après plus de 2 ans d’existence, on a tout de même l’impression que cette techno se cherche encore et que, du coup, la communauté J2EE n’a pas encore confiance en GWT pour démarrer ses projets. Ce manque d’API robuste ne fera que renforcer cette tendance.

Est-ce possible ? Réponse : Google est ton ami Très peu de sites (comme par exemple onGWT) référencent ce qui se fait en GWT au niveau des outils, des frameworks… Il devient assez laborieux de trouver une API pour un besoin spécifique. N’oublions pas que GWT émule les packages java.util, java.lang et java.io. Suffisant pour certains projets, mais pour de grosses applications de gestion il en faudra d’autres…

Un puzzle ! C’est certainement ce qui ressort le plus des projets GWT. Les librairies se récupèrent à droite, à gauche sur Google, il y en a partout avec peu de référencement… GWT devrait peut-être intégrer directement des APIs reconnues qui ont fait leurs preuves (comme par exemple Java 7 avec Joda-Time)…

Autrement dit, et c’est aussi une des conclusions de GWT in Action, GWT permet de développer très facilement des applications Ajax sans forcément connaitre Javascript (tout en laissant la possibilité de coder directement en Javascript). Il y a bien sûr encore des choses à revoir/améliorer mais le langage est en très bonne voie et les librairies existantes font le travail demandé.

Cependant, devez-vous foncer tête baissée sur GWT car vous démarrez un nouveau projet Web / Ajax et vous ne savez pas quelle technologie choisir (GWT, Flex, Silverlight, JavaFX…) ? Impossible de répondre de manière générale pour tous les projets, cela dépend du back-end existant, des besoins du projet, du temps imparti… Sachez en tout cas que GWT est un excellent compromis entre Ajax, Java et Javascript et que personnellement, sur les projets auxquels j’ai participé, je ne regrette absolument pas son utilisation !