Deuxième journée de la réunion annuelle des Java-holic européens. Le programme est chargé :

• Total cost of ownership
• Unleash your processor(s)
• What's new in hibernate
• iPhone/Ipad development from Java perspective
• Harnessing the power of HTML5 Web Sockets to create scalable real-time applications
• GPars: Parallel programming concepts for the JVM in Groovy
• Cloud Computing with Scala and GridGain
• How Java powers large online retail sites

Suivez le guide ...

Total cost of ownership

La keynote de la seconde journée est tenue par Ken Schwaber, le co-fondateur de Scrum. Il revient sur les bénéfices à tirer de Scrum. Le message n'est pas très neuf pour la communauté des agilistes mais il est toujours bon de se rappeler pourquoi nous essayons de changer les façons de faire. Dans un style très posé, il nous expose quelques axes pour inviter les spectateurs à s'améliorer.

• Les gens ne sont pas des ressources
• Il est important de définir la notion de tâche "terminé" pour chaque projet (Definition of Done)

Si votre définition de Done laisse de côté des points importants comme l'écriture de tests ou l'intégration aux autres composants, l'équipe accumule rapidement une grande quantité de tâches non réellement finies. Cette dette devra être prise en compte en mettant en place des sprints dédiés à la stabilisation. Cette solution est bien souvent beaucoup plus coûteuse que de correctement définir et de respecter la definition of done au fil des développements.

Il annonce également le lancement d'une formation de 5 jours spécialement adaptée aux développeurs destinés à travailler en équipe Scrum : Professional Scrum Developper Program.

Unleash your processor(s)

Václav Pech nous fait ensuite une présentation sur différents patterns de programmation concurrente. Selon lui, pratiquement aucune application ne profite des architectures multicore et celles qui en profitent ne le font que par hasard.
Václav présente ensuite un ensemble de patterns notamment :

• Parallel Arrays qui permet d'effectuer des opérations comme du filtrage ou du calcul sur des éléments stockés dans une collection en parallèle. Tout ce qu'il y a à faire, c'est de définir les opérations qui seront appliquées à la collection. Ceci de facon simple sans manipuler de thread, ni gérer de moniteur transactionnel.

• Fork and join A partir du JDK 7, une nouvelle API du package java.util.concurrency va permettre de définir des tâches et de gérer leur exécution. Le principe de base est de diviser les données à traiter en petites unités de travail et de traiter ces unités en parallèle. Les résultats obtenus en retour seront ensuite agrégés.

Václav présente ensuite d'autres patterns tels que le dataflow concurrency, les actors, les agents, le principe de Shared Mutable State et de Persistent data structures. Ces patterns seront présentés plus en détail dans un futur article dédié à la programmation concurrente.

What's new in hibernate

Emmanuel Bernard présente les principales évolutions intégrées dans la dernière version d'Hibernate. Le but principal de la version 3.5 était d'implémenter la spécification JPA2. Il revient sur quelques fonctionnalités de la spécification. Notamment :

• Packaging

Hibernate Annotations et Hibernate Entity Manager sont maintenant dans le même projet que Hibernate Core. Les releases sont maintenant toutes synchronisées, ce qui met fin à la complexe matrice de compatibilité. Les releases du projet d'audit et de gestion de version Envers seront également synchronisées avec le core.

• Application de formule

Il est désormais possible d'appliquer des fonctions avant la lecture ou l'écriture dans une colonne par la base de données. Un des cas possibles peut être l'utilisation des fonctions d'encryption native d'un SGBD.

• Fetch profile

Pour éviter de générer un trop grand nombre de requêtes, il est possible de charger un arbre d'entités lors du chargement par clé primaire. On paramètre alors dans le fichier de mapping la stratégie de chargement.

La stratégie sera statique et appliquée que l'on charge les entités par la méthode get, les Criteria ou le chargement implicite durant la navigation à travers une association. Une des solutions était de créer un ensemble de méthodes, du type loadCustomer, loadCustomerWithAddress, loadCustomerWithOrders, et d'utiliser une requête HQL pour dynamiquement appliquer une stratégie de chargement (en HQL : inner join fetch). Mais ceci ne permet pas de définir des stratégies dynamiques pour les chargements implicites.

Hibernate propose maintenant une manière plus simple de gérer les stratégies de chargements. On peut désormais définir dans le fichier de mapping plusieurs stratégies pour une association.

et définir la stratégie à utiliser pour chacune des sessions avec la méthode suivante :

iPhone/iPad dev from Java perspective

Ognen Ivanovski, de la société Netcetera, nous présente son retour d'expérience sur les développements pour l'iPhone (et donc pour l'iPad). Étant développeur Java à la base, il nous expose les écueils auxquels risquent de se heurter les développeurs Java en arrivant sur cette plateforme, ainsi que les points importants à garder en tête pour le design.

N'espérez donc pas voir apparaitre une méthode magique pour développer en Java pour l'iPhone. Comme Ognen l'a rappelé, Apple n'autorise dans AppStore que les applications rédigées en Objective-C. Il commence par un petit rappel sur l'environnement de développement sanctifié par Apple, à savoir : XCode, Interface Builder, iPhone Simulator et Instruments (pour le profiling).

Voici, d'après lui, les facteurs clés à garder en tête lors d'un développement pour cette plateforme :

• Le hardware est limité, en mémoire comme en CPU : Cependant la performance est cruciale. Il faut donc designer ses applications pour la vitesse et les tester sur de vrais appareils. L'émulateur fourni dans le kit de développement ne rend pas compte des performances réelles. Pensez donc à gérer votre mémoire: ici, pas de Garbage Collector. Et si par hasard le SDK ne vous fourni pas ce que vous voulez, vous pouvez toujours embarquer des librairies en C pur.
• La résolution est différente : Là encore, un test sur un device réel ne saurait être remplacé par un test sur l'émulateur, des changements subtils peuvent impacter fortement l'effet obtenu, à cause de la taille et de la résolution de l'écran.
• Le mode d'utilisation change : En développement web on suppose l'utilisateur assis avec clavier, souris, etc. Mais en mobile, il sera plutôt en déplacement, ou dans un canapé avec l'iPad. Ceci doit être pris en compte dans le design. L'interface multitouch, la taille des doigts, etc., tous ces paramètres doivent être exploités intelligemment.
• Les barrières posées par Apple : Le iPhone Developer License Agreement est fluctuant et contraignant. Il existe une constante inquiétude de la censure quand on développe. La médaille de ce revers est que, si votre application passe la censure, les utilisateurs feront confiance à l'AppStore et n'auront aucune réticence à l'installer sur leur iPhone/iPad.
• Chaque application est partie intégrante de l'appareil : D'après les retours d 'Apple, les utilisateurs d'iPhones ne se servent que marginalement de la fonction de recherche. Ils trouvent une application qui leur récolte et présente les données d'un domaine particulier. Il faut donc penser une application comme partie intégrante du device physique et travailler au mieux son intégration.

Il enchaîne sur un rapide exposé des API disponibles, puis met en garde son auditoire sur les méfaits du hype. En effet, le positionnement marketing peut amener à se lancer dans un développement iPhone mais il faut faire les choses bien. Une application médiocre, même si elle offre une visibilité sur l'AppStore, sera mal notée par les utilisateurs et occasionnera donc une perte d'image.

Une présentation avec très peu de technique mais qui donne une bonne idée des contraintes à considérer pour ne pas perdre son temps lors d'un premier développement.

Harnessing the power of HTML5 Web Sockets to create scalable real-time applications

Peter Lubbers, de chez Kaazing Corporation, nous présente les avantages à tirer d'une communication full-duplex entre navigateurs et serveurs web. Il commence par rappeler les besoins de réactivité des pages web et les problèmes des solutions actuelles :

• polling : Basé sur des requêtes AJAX périodiques pour récupérer les données. Le martelage du serveur par des requêtes AJAX en provenance de tous les clients connectés pose des problèmes de charge et d'occupation de la bande passante (chaque requête arrive avec ses headers HTTP). De plus cette solution ne fait que fournir du presque temps réel et scale très mal.
• long polling : Technique des architectures Comet. Cela permet d'éviter de marteler le réseau pendant les périodes où il n'y a pas de données à fournir, mais dès que le flux est continu, la fréquence des polling augmente et revient au même que le polling classique.
• streaming : fonctionne bien mais la conservation d'une connexion ouverte trop longtemps peut poser des problèmes avec les proxies et firewall sur la route.

Peter enchaîne sur une démonstration de Comet et de son occupation du réseau en capturant les trames réseau avec WireShark, et nous présente enfin la solution d'avenir : les WebSockets de HTML5.

Nous avions parlé il y a quelques temps des API Javascripts qui y sont liées. Un autre point mis en avant est qu'une fois établi, les communications passant par une WebSocket se passent de header HTTP (871 octet en moyenne) et sont remplacées par 2 octets qui encadrent chaque message, diminuant d'autant l'occupation de la bande passante.

Il détaille un peu l'aspect sécurité de la chose, les WebSockets sont également disponibles en version sécurisé, basé sur TLS (comme HTTPS) et s'établissent simplement par une poignée de main (Handshaking) sur HTTP. Actuellement les WebSockets du coté browser ne sont supportés que par Chrome 4.0+, et les nightly builds de WebKit. Opera et Firefox promettent de le supporter bientôt.

Il termine par la démonstration d'une application de Poker, avec WebSockets liés à un Kaazing Gateway et nous montre les trames réseau.

On peut regretter tout de même que Peter ne fasse aucun autre commentaire sur la partie serveur que d'évoquer le Kaazing WebSockets Gateway. A aucun moment la spécification Servlet 3.0, ni GlassFish, ni Jetty, ne sont évoqués.

GPars: Parallel programming concepts for the JVM in Groovy

Dans une session presque purement technique, Dierk König nous présente la librairie GPars, destinée à apporter la facilité à la gestion de la concurrence dans Groovy. Il commence par un rappel reprenant les concepts déjà exposés par Václav Pech dans sa session du matin, puis enchaîne sur une session de live coding pour démontrer la simplicité d'usage de la librairie.

Parmi les exemples codés devant nos yeux ébahis, on trouve notamment :

• la parallélisation d'opérations sur des collections
• les opérations asynchrones avec pool de thread
• les Actors inspiré de Scala
• les Agents inspirés de Clojure, destinés à protéger des ressources non thread-safe

Il est pratiquement impossible de coucher un live-coding dans un article, mais la vidéo devrait sortir en même temps que les autres tournées dans la salle 5 de Jazoon. Vous les retrouverez dans la revue de presse, dès leur sortie.

A noter qu'un problème avec son IDE favori l'a forcé à utiliser uniquement la Groovy Console, exercice mené donc sans filet, et avec brio.

Cloud Computing with Scala and GridGain

Nikita Ivanov, de chez GridGain Technologies, vient nous exposer les travaux de sa société autour de Scala. Il commence par nous rappeler le contexte en revenant de façon synthétique sur certaines définitions :

• Grid : 2 ordinateurs ou plus fonctionnant en parallèle sur des parties distinctes d'une tâche commune
• Grid Computing : Grid de calcul et data Grid fonctionnant de concert
• Cloud : Virtualisation de Data Center
• Cloud Computing : Cloud et Grid Computing

GridGain Technologies a choisi d'adopter un langage plus simple pour exploiter leur architecture de Cloud Computing. Nikita nous explique que Groovy a été écarté à cause de ses performances, que JRuby a été écarté pour des problèmes d'intégrations et que Scala remplissait tous les critères de choix de GridGain :

• Scalable
• Post fonctionnel
• Performances égales à Java
• Statiquement typé
• Pleinement compatible Java

Ils ont donc développé un DSL nommé ScalaR, qui permet de créer des programmes à lancer dans un Cloud GridGain en quelques lignes. S'en suit une nouvelle session de live coding, comparant l'approche traditionnelle de l'API GridGain, et l'utilisation de ScalaR. On devine assez bien quelle version a remporté la manche. DSL intéressant, dommage que le manque de temps a forcé Nikita à écourter un peu la démonstration.

How Java powers large online retail sites

Notre journée se conclut par une présentation de Robert Brazile, CTO chez ATG, qui rend hommage à l'apport des technologies Java au monde du commerce en ligne. Il revient sur la place grandissante de la vente sur internet dans l'ensemble des ventes sur le territoire américain, puis nous expose les problématiques générales des sociétés de vente :

• haute disponibilité : les sites de vente en ligne doivent rester disponibles malgré les pics d'affluence. Les travaux sur le load balancing ont beaucoup apporté.
• la vitesse avant tout : bien plus que le design graphique, c'est la performance d'une application qui est cruciale. Un peu trop d'attente, trop de clic à faire, et la vente est perdu.
• la couche de présentation séparée : pour pouvoir déléguer les manipulations de présentation et de gestion des backend à des équipes séparées. Cela évite que les développeurs soient pris par des tâches "subalternes" alors qu'ils doivent réfléchir à des problèmes complexes comme la charge ou la récupération des données.
• éviter de payer l'infrastructure nécessaire aux pics de charge pendant les creux : grâce aux avancées dans le Cloud computing, les vendeurs en ligne ont pu faire beaucoup d'économies.

Robert a multiplié les anecdotes sur les ratés de l'automatisation, comme ce moteur de recherche qui a mal réglé son moteur de suggestion :

search for : abortion => Did you mean adoption ?
(trad. : rechercher : avortement => Vous voulez dire adoption ?)

Son expérience encyclopédique du monde des systèmes d'informations pour les sites de vente en ligne lui a servi à illustrer à quel point le langage Java a permis la percée des techniques de vente en lignes modernes. Il prévoit d'ailleurs que cela continue dans les années à venir avec certains sujets qui animent déjà la communauté Java :

• Virtualisation et Cloud Computing : pour toujours plus de scalabilité
• Bases de données NoSQL : pour un meilleur accès aux données, chaque archi répondant à des besoins spécifiques
• Scripting : PHP, Ruby, Groovy et autres, pour des modifications rapides sur les sites publics
• Frameworks : Rails, Grails, Lift et autres, pour concevoir et déployer rapidement des sites vitrines à faible durée de vie
• Parallélisme et concurence : Pour exploiter de façon efficace les architecture multi-core et le Cloud

Java est mature donc, mais certainement pas proche de la retraite.

Epilogue

Nous avons dû choisir entre les sessions Jazoon Rookie et notre avion. Vous devinez sûrement ce que nous avons décidé . Dans l'ensemble, Jazoon est toujours une conférence très intéressante, les orateurs sont de très bon niveau et très accessibles pour discuter en dehors des présentations.

Un grand merci aux organisateurs et aux orateurs. Nous attendons avec impatience les vidéos.

Premières observations :

• légère baisse d'affluence par rapport à l'année dernière,
• forte présence de JavaFX avec pas moins de six sessions, ainsi que d'OSGi,
• très bonne ambiance et organisation,
• excellents speakers, merci à eux.

Nous allons vous rendre compte des sessions suivantes :

• Java SE and JavaFX: The Road Ahead
• Client / Server 2.0 with Java and Flex
• Frameworks and security : how they kill your security scanning
• Object of value
• Construction techniques for domain specific languages
• Servlet 3.0
• 97 things every programmer should know

Java SE and JavaFX: The Road Ahead

Jazoon 2010 commence par une keynote de Danny Coward sur l'évolution du langage java. Danny revient sur l'évolution de Java depuis le début du langage (Java a 15 ans depuis le 24 mai). Il y a désormais plus de 7 millions de développeurs Java à travers la planète, près d'un milliard de JVM déployées, et plus de 2 milliards de téléphones mobiles avec une JME.

Il nous montre également une vidéo de 1995, avec James Gosling présentant un prototype de PDA avec des interactions proches des smartphones récents, notamment la navigation dans les menus, l'écran tactile, un véritable iPhone préhistorique.

Danny insiste fortement sur l'effort de modularisation de la JVM, illustré par le projet Jigsaw, pour améliorer la taille de la JVM et sa rapidité de démarrage. Il nous parle également de la gestion du parallélisme avec le récent travail sur le garbage collector G1, mais aussi de l'API fork/join et ParallelArray sur laquelle nous reviendrons en détails.

Danny nous parle également du grand nombre de langages qui tournent sur la JVM : près de 200. Il met en lumière le projet Da Vinci Machine, destiné à fournir des optimisations bas niveau aux langages tiers pour obtenir des performances proches de Java sur tous les langages tournant sur la JVM.

Puis viennent toutes les nouveautés du langage attendues prochainement :

• nouvelles annotations,
• amélioration de l'inférence de type pour les Generics (mieux connu sous le nom de 'diamond operator')
• possibilité de catcher plusieurs exceptions à la fois,
• supports des chaines de caractères pour les commandes switch/case,
• support des closures à travers le projet Lambda.

Danny consacre également beaucoup de temps pour nous parler de JavaFX. Il a tenu à rappeler que JavaFX est bien vivant, la preuve en est qu'il y a eu 4 releases en 18 mois. Parmi les nouveautés de la version 1.3 on peut noter :

• l'arrivée de nouveaux composants graphiques plus scalables,
• la nouvelle stack graphique nommée Prism,
• des optimisations : il annonce un démarrage 2 à 3 fois plus rapide sur un Java SE 6 update 18,
• JavaFX TV : annoncé comme nouveauté mais déjà présent dans la version 1.2, avec son émulateur de TV.

Et pour finir cette keynote de lancement, il nous fait la démonstration d'une partie du site des JO de Vancouver 2010, écrite avec JavaFX.

Si l'on se replonge dans les sessions de l'année dernière, il est troublant de voir que les sujets abordés dans cette keynote sont exactement les mêmes que ceux abordés par James Gosling et Danny Coward l'an passé, au même endroit (si l'on omet l'omniprésence de JEE6 en 2009). Si nous étions taquins, on pourrait presque dire que cette keynote d'ouverture est un copier / coller de celle de l'année dernière. Et si nous étions vraiment irrévérencieux, nous dirions que depuis un an, Sun / Oracle n'a pas grand chose à annoncer concernant Java.

Client / Server 2.0 with Java and Flex

James Ward nous présente les interactions entre le monde Flex et le monde Java. James revient sur toutes les méthodes de communication, d'une jsp renvoyant du contenu en xml, en passant par les appels SOAP, jusqu'à l'utilisation des annotations fournies dans spring-blazeds.

L'annotation @RemotingDestination permet d'exposer automatiquement un service Java vers le monde Flex en utilisant le protocole AMF.

Il insiste également sur le coût du parsing de chacun des formats. AMF est peu coûteux en CPU et en mémoire comparé au parseur XML. Ce point peut être important dans le cadre de clients Flash sur mobile, ne possédant pas la même puissance de calcul et de mémoire qu'un desktop. Pour conclure, James nous présente Flash sur un téléphone Android.

Frameworks and security : how they kill your security scanning

Christian Hang, de chez Armorize Technologies, nous fait part de son point de vue sur les problèmes d'audit de sécurité posés par l'utilisation des frameworks. Il commence par un rappel assez complet sur la sécurité en général et les méthodes de détection de failles :

• black box testing : simulation d'attaques extérieures
• white box testing : analyse statique de code pour trouver des failles potentielles (ou SCA : Static Code Analysis)
• analyse dynamique : mise en place d'agents ou de moniteurs sur une application en fonctionnement pour tracer les failles

Il expose rapidement les risques de détection de faux positifs et faux négatifs et leurs conséquences avant d'approfondir sur l'analyse statique de code et ses limites. C'est là qu'arrivent les frameworks et le défi lancé aux outils de SCA. En effet, la forte utilisation de fichiers configuration casse la chaine d'invocation que tentent de suivre les outils de SCA. Comme chaque framework possède ses propres normes de configuration, il est très complexe de poser une méthode générique. De plus comme les frameworks sont des librairies tierces, la chaine d'invocation va se perdre au sein d'un jar et oblige à inspecter le framework en lui-même et non l'application seule. Il nous fait la démonstration de son propos avec le déroulement d'une requête dans Struts.

Christian termine en exposant les solutions qu'il entrevoit à ces problèmes, à savoir la génération de code source 'glue', basée sur les fichiers de configuration, qui permette aux outils actuels de SCA de continuer à suivre la chaine d'invocation jusqu'au bout. Ce code 'glue' serait injecté avant le passage de l'analyse de code et évidemment pas committé sur l'application.

Avec ses propositions, Christian nous ouvre de nouvelles perspectives d'améliorations pour les outils de SCA. Il y a du chemin à faire mais le gain en détection automatique de failles est potentiellement énorme.

Object of value

Première présentation de la journée pour Kevlin Henney. Il revient sur le concept de Value Object en insistant beaucoup sur la différence fondamentale qui existe entre une Valeur et son implémentation.

L'exemple le plus parlant qu'il donne est celui d'un md5 de fichier. Pour être manipulé, nous aurons sûrement tendance à le stocker dans un String, mais fondamentalement, ce n'est pas une quelconque chaîne de caractères, c'est un MD5 qu'on souhaite manipuler. Ce qui devrait se traduire par la création d'un Value Object MD5.

Pour un rappel sur ce concept, vous pouvez vous pencher sur ce blog.

Kevlin Henney nous invite à réfléchir à la meilleure façon de manipuler des Valeurs dans nos programmes et non un énorme assemblage de String et de numériques.

Nous reparlerons prochainement de ses idées sur la question.

Construction techniques for domain specific languages

Neal Ford, de ThoughtWorks, nous parle de l'élaboration de DSL et des outils les plus adaptés à cela. Après un rappel sur les motivations de l'écriture de DSL et la différence fondamentale entre une API et un DSL, il nous livre ses cinq clés pour l'élaboration de DSL :

• langage de programmation
• langage naturel, proche d'un langage oral
• focalisé sur un aspect particulier du domaine
• expressivité limitée
• ne doit pas être Turing-complet

Il tente alors une approche des principes exposés en Java, code à l'appui. De son point de vue, il n'est pas possible de réaliser de vrais DSL en Java pur. Ce qui s'en rapproche le plus est le method chaining, qui consiste à retourner this à la fin de chaque méthode pour pouvoir enchainer les appels. Un bon exemple illustrant ce principe est l'API Criteria d'Hibernate :

Puis il passe au langage Groovy, qui lui semble bien plus adapté que Java pour ce cas de figure. Certains aspects de Groovy facilitent la tâche :

• le typage dynamique
• les closures
• 2 techniques de classes ouvertes : les Categories, et les MetaClasses

Ce qui amène Neal a parler de EasyB, projet codé en Groovy pour rédiger des spécifications en BDD, de la forme :

EasyB étant basé sur RSpec, un projet BDD pour Ruby, Neal enchaîne naturellement sur les avantages de ce langage pour la rédaction de DSL, à savoir :

• classes ouvertes
• aliasing de méthodes
• polishing, méthodes de nettoyage de code 'presque' Ruby en 'vrai' Ruby.

Pour information, il est tout à fait possible de réaliser ses DSL en Ruby et de les faire exécuter en Java, grâce à JRuby. Neal nous livre donc son choix pour les DSL : Ruby. Et il termine sa présentation en rappelant les éléments indispensables à conserver en tête lors de la rédaction de DSL :

• c'est un langage de programmation limité à un aspect du domaine.
• construire par composition et non par élaboration : il vaut mieux faire beaucoup d'opérateurs simples qu'on composera en utilisant le DSL.
• démarrer par la fin : il faut poser la syntaxe que l'on souhaite obtenir dès le début et créer le DSL de façon à respecter cette syntaxe.
• évolution, pas révolution : un DSL se construit petit à petit, il ne faut pas espérer penser tous les opérateurs dès le début, les besoins apparaitront à l'usage.

Servlet 3.0

Ravij Mordani présente la spécification Servlet 3.0, introduite dans la plateforme JEE6. Il nous présente les améliorations selon quatre axes qui reflètent le nouveau visage des Servlets.

Facilité de développement

Profite des améliorations de Java 5, comme les annotations.
On peut directement annoter une servlet plutôt que de devoir la configurer dans le fichier web.xml. Le très verbeux

devient donc

On notera qu'il est toujours obligatoire d'étendre HttpServlet et de fournir une implémentation aux méthodes doGet, doPost, etc.

De la même manière, on peut définir des Filter ou des ContextListener directement par annotations. Le fichier de configuration web.xml devient optionnel, les annotations suffisent. Si toutefois vous le voulez, vous pouvez écrire un fichier web.xml, qui surchargera alors les directives des annotations.

La configuration peut également être faite de façon programmatique, grâce à une nouvelle API, mais uniquement au chargement du contexte.

Pluggabilité

La notion de web-fragment fournit un moyen de partitionner le descripteur de déploiement. On peut directement fournir de la configuration dans un jar, en plaçant un fichier nommé web-fragment.xml dans META-INF. De la même manière on peut intégrer des JSP dans les jars dans le répertoire META-INF/resources/.

La notion de plug-in de container apparait également. Elle est déjà utilisée notamment par les implémentations de référence JSF (Mojora) et JAX-RS (Jersey).

Exécution asynchrone

L'exécution asynchrone de servlet permet de s'affranchir du pattern Thread by request. Les requêtes demandant un traitement long au back-end, telles que des requêtes bases de données couteuses ou les appels à des systèmes externes de type webservice, peuvent désormais être facilement exécutées de manière asynchrone. Cela permet de rendre le thread disponible pour le traitement des autres requêtes.
Cette fonctionnalité est également très utile pour le développement de fonctionnalités poussant des données vers le client. Le thread n'est plus en permanence bloqué pour un client, mais uniquement lors de l'arrivée d'un évènement.
Pour que le mode asynchrone fonctionne, il faut que toute la chaîne de traitement soit effectivement compatible (filtres, servlets...).

Sécurité

Un ensemble d'annotations permet désormais de gérer le contrôle d'accès à une servlet. On peut également obliger l'utilisation d'un protocole sécurisé (HTTPS) pour l'appel à la servlet. Les 4 annotations suivantes : @DenyAll, @PermitAll, @RolesAllowed, @TransportProtected pourront être utilisées sur les méthodes traitant les requêtes dans HttpServlet (doGet, doPost et les autres) ou bien directement sur la classe.

Il est aussi possible d'implémenter directement la méthode d'authentification HttpServletRequest.login(String username, String password);

97 faits que tout programmeur devrait connaître

Pour clore la journée, tout le monde se regroupe dans la salle 5 (la plus grande) pour écouter Kevlin Henney présenter quelques conseils extraits du livre publié par O'Reilly 97 things every programmer should know

Le livre étant très conséquent, il a choisi de se focaliser sur :

• Apprenez à estimer : Learn to estimate
• Ne commentez que ce que le code ne dit pas : Comment only What the code cannot say
• Encaspulez un comportement, pas seulement un état : Encapsulate behavior not just state
• La règle du boyscout : The boy scout rule (Try to leave this world a litte better than you found it...)
• Le test est la rigueur professionnelle du développement logiciel : Testing is the Engineering rigor of software development
• Écrivez des tests accessibles aux autres : Write test for people

Les anecdotes et la verve de Kevlin nous font passer un très bon moment, avant de nous rendre au Jazoon Networking Event, où tous les participants peuvent souffler un peu autour d'un verre, partager leurs impressions sur les différentes sessions de la journée, ou discuter avec les speakers.

Le programme s'annonce chargé et diversifié, choisir entre les conférences en parallèle risque d'être très dur. Voici quelques-uns des sujets principaux :

• JEE6
• RESTful SOA
• OSGi
• Security patterns
• Scala in the cloud
• JavaFX
• Parallel programming with Groovy
• Maven 3.0
• Hibernate from JPA2 perspective

Le tout sera porté par des acteurs J2EE de renommée mondiale : Danny Coward, Ken Schwaber, Dan Allen, Emmanuel Bernard ...

Les journées risquent d'être denses et nous espérons y collecter un maximum d'informations que nous vous relayerons ! Nous avons décidé de ne couvrir que les deux premières journées, qui nous ont semblé être les plus attrayantes au niveau du programme.

Vous pourrez vivre Jazoon en direct, mardi et mercredi prochain, en nous suivant sur Twitter.

Xebia France :

Julien Buret :

Aurélien Maury :

Actualité éditeurs / SSII

• StreamBase lie le Complex Event Processing à Twitter
• Atlassian Summit : le présent et l'avenir des outils Atlassian

Le coin de la technique

• Sortie d'Eclipse Galileo
• Des applications Web modulaires avec SpringSource Slices
• Que devient JMX 2 ?

Evènements de notre communauté en France et à l'étranger

• Retour sur la conférence Jazoon

Actualité éditeurs / SSII

StreamBase lie le Complex Event Processing à Twitter

StreamBase est un éditeur qui fournit une solution de Complex Event Processing (CEP) très populaire dans le monde de la finance. Il s'agit d'un middleware capable d'analyser un flux de messages en temps réel pour y reconnaître des évènements complexes.

Dans un communiqué de presse, l'entreprise annonce proposer un connecteur Twitter pour sa solution de CEP. Il devient ainsi possible pour les systèmes d'information du monde de la finance d'analyser les messages Twitter pour en extraire un sentiment global en temps réel pouvant être utilisé dans un système de trading ou d'analyse marketing.

John Davies, directeur technique d'une société américaine spécialisée dans ce type de traitements financiers, analyse cette annonce et avoue qu'après avoir été sceptique quant à cette idée au premier abord, il y voit désormais une opportunité d'améliorer la réactivité des systèmes par rapport à l'utilisation de simples flux Reuteurs apportant l'information plus tardivement.

Ce type d'annonce permet surtout de réaliser le potentiel de la technologie CEP appliquée à l'exploitation de sources diverses provenant de l'intérieur comme de l'extérieur du système d'information de l'entreprise.

Atlassian Summit : le présent et l'avenir des outils Atlassian

Au début du mois de juin s'est déroulé l'Atlassian Summit à San Fransico. Il s'agissait de la première conférence du genre pour l'éditeur et a pu profiter de l'occasion pour présenter toutes ses nouveautés à venir et revenir sur les dernières évolutions de ses produits. L'ensemble des sessions de cette conférence sont maintenant accessibles librement en ligne.

Nous nous attarderons principalement sur le keynote de Mike Cannon-Brookes, CEO et co-fondateur d'Atlassian, qui résume la majorité des éléments à retenir.

Confluence

La version 3.0 de Confluence a été finalisée il y a peu. Elle apporte principalement :

• Ajout d'un macro browser permettant de naviguer facilement parmi les macros disponibles
• Apport de nombreuses extensions de nature "sociale" avec une gestion de réseaux, un microblogging de type Twitter, un espace personnel repensé
• Gain significatif de performance lors de la navigation et de l'édition

Jira et GreenHopper

Jira 4.0 n'est pas encore finalisé, mais est dors et déjà disponible en version beta. Il apporte quelques nouveautés intéressantes :

• Refonte du dashboard de Jira. Il devient largement personnalisable grâce à l'ajout de gadgets à l'image d'iGoogle
• Introduction du Jira Query Language (JQL) permettant de faire des recherches avancées simplement grâce à un système de complétion. Les résultats des requêtes peuvent alors être ajoutés au dashboard
• Le plugin GreenHopper, permettant d'exploiter le moteur de tâches de Jira pour gérer un projet agile (gestion d'itérations, production de burndown charts, ...), devient un produit Atlassian. L'éditeur en ayant annoncé l'acquisition lors du Summit.

Open Social

La généralisation de l'utilisation de l'API Open Social au sein des produits Atlassian est probablement ce qui restera le plus marquant. Ainsi la plupart des produits Atlassian proposeront des gadgets Open Social pouvant être intégrés à n'importe quel conteneur Web s'appuyant sur cette technologie.

Concrètement, il est alors possible d'intégrer un gadget Jira au sein de l'interface de Gmail afin de simplifier la saisie d'une nouvelle anomalie suite à la réception d'un mail décrivant un problème. De même, le dashboard de Jira 4.0 devenant un conteneur Open Social, il est possible d'intégrer un gadget indiquant l'état des derniers builds de Bamboo conjointement aux gadgets indiquant l'état des anomalies et tâches Jira actives. Open Social devient ainsi le vecteur d'intégration des produits Atlassian.

Fisheye, Crucible et Eclipse Connector

Fisheye 2.0 et Crucible 2.0 ne sont également pas encore finalisés mais accessibles en beta. Ils apporteront tous deux une meilleure intégration à Jira, une interface utilisateur refondue et une vue permettant de visualiser l'activité des développeurs sur les différents projets.

Atlassian a également publié fin mai la version finale de l'Eclipse Connector, un plugin permettant d'intégrer certaines fonctionnalités des produits Atlassian au sein d'Eclipse :

• Jira est un task repository pour Mylyn, la gestion de tâches s'intègre donc à tous les niveaux dans l'IDE. Il est par exemple possible avec un clic d'ajouter, en pièce jointe de l'anomalie Jira, le context Mylyn et, dans un autre environnement, de le restituer d'un autre clic.
• Une vue est dédiée à Bamboo et permet d'observer et d'interagir avec les builds du serveur d'intégration continue de l'éditeur
• Il devient possible d'effectuer les code reviews Crucible directement depuis Eclipse
• Il est possible de lancer l'affichage de la page Fisheye correspondant à un fichier spécifique par simple clic droit

Ces fonctionnalités étaient déjà disponibles pour IntelliJ, elles le sont maintenant également pour l'IDE Java le plus populaire.

Atlassian continue de se montrer très innovant en apportant un lot intéressant de nouvelles fonctionnalités sur ses produits déjà très populaires. L'acquisition de GreenHopper lui permet quant à elle de se positionner sur le créneau des applications de gestion de projets agiles que Thoughtworks Studios commençait à investir avec Mingle.

Le coin de la technique

Sortie d'Eclipse Galileo

Comme chaque année depuis 2004, fin juin sera marquée par la sortie d'une nouvelle version d'Eclipse IDE.

Après Callisto, Europa et Ganymède, voici venu Galileo (ou Eclipse 3.5).

Difficile de faire un résumé des 24 millions de lignes de codes ni même de la trentaine de projets qui le compose, cependant plusieurs nouvelles fonctionnalités ressortent. A signaler qu'un top 10 de ces nouveautés a d'ailleurs été publié par Ian Bull sur le site d'Eclipse Source (série de 10 billets).

On notera ainsi :

• Compatibilité avec Mac OS X (portage SWT vers Cocoa).
• Memory Analyzer Tool (MAT), un outil d'analyse de heap (consommation, fuite mémoire ...).
• Mylyn (gestion de tâches, synchronisation...) qui n'est pas nouveau mais qui devient de plus en plus populaire avec le support entre autre de Jira.
• XText qui permet la création de DSL (auto-complétion, coloration syntaxique ...).
• Rich Ajax Platform (RAP) qui permet de déployer son application en tant que WebApp.
• SWT Browser qui gère le pont entre Java et Javascript dans les 2 sens.
• Mylyn WikiText, un éditeur de fichier wiki.
• Plateforme (p2 avec update manager revu, target platform, deploy into self pour tester ses plugins ...).

Le téléchargement se passe par ici avec comme d'habitude plusieurs packages disponibles qui vont de la version classique à la version Java, JEE ou RCP sans oublier, pour les non javaistes, les versions C++ et PHP. D'autres packages ciblant le reporting ou la modélisation sont aussi disponibles.

Et bien sûr, rendez-vous est pris l'année prochaine même date (par Chris Aniszczyk) pour la release d'Eclipse 3.6 qui se nommera Helios !

Des applications Web modulaires avec SpringSource Slices

Rob Harrop a présenté une ébauche d'un nouveau projet SpringSource appelé Slices.

Il s'agit d'un framework basé sur dm Server 2.0 et permettant le développement d'applications Web modulaires. Cette modularité est bien sûr offerte par OSGi, ce qui lui en apporte les caractéristiques particulières : gestion de dépendance versionnées et chargement et arrêt des modules à chaud.

Concrètement une application utilisant Slices offrira un module Web host et un ensemble de modules fils appelés slices. Chaque module apporte du code applicatif et un ensemble de ressources Web (CSS, JavaScript, JSP, images). Le framework offre alors une couche d'abstraction aux slices leur permettant de posséder leur propre session et servlet mappings. Il offre également l'infrastructure nécessaire pour rendre les ressources du module host visibles par tous les autres et pour permettre aux modules de se détecter les uns les autres et ainsi d'opérer des altérations visuelles et comportementales en conséquence.

Dans son état actuel, Slices n'offre qu'une infrastructure de base, la version finale devrait apporter en supplément :

• Un framework de composition d'UI. On imagine que celui-ci apportera des tags permettant l'affichage conditionnel en fonction de la présence ou non de certains modules. Cette fonctionnalité est actuellement gérée manuellement par des EL dans l'application d'exemple
• Le support des servlet filters
• Une intégration à Tiles 2
• L'intégration à SpringSource Tool Suite

Slices apportera donc de nouvelles possibilités en apportant la modularité jusqu'à la couche Web. Ainsi, parallèlement à son offre tc Server, résolument orienté vers le marché actuel, SpringSource continue d'innover en apportant des fonctionnalités supplémentaires à son offre modulaire centrée autour de dm Server.

Que devient JMX 2 ?

JMX est une API standard Java permettant le monitoring et le management d'applications, elle est définie par la JSR-3 et étendue par la JSR-160 (Remote JMX). Depuis sa création en 1998, l'API a évoluée au fil des maintenance releases de sa JSR, incrémentant au passage sa version depuis 1.0 jusqu'à 1.4. Au départ disponible sous forme de librairie externe, JMX a finalement été intégré au JDK 5.0 puis mis à jour dans le JDK 6.0, fin 2006, pour s'aligner avec sa dernière version.

La prochaine évolution majeure de JMX est la version 2.0, cette fois-ci définie dans une nouvelle JSR, la JSR-255 (JMX 2.0). Actuellement en statut early draft review, il est dors et déjà possible de se rendre compte des chantiers prévus :

• Des namespaces permettant de préfixer les noms des MBeans afin d'offrir une meilleure scalabilité lors que de très nombreux MBeans sont manipulés.
• Le cascading permettant de fédérer un ensemble de MBeans situés sur des serveurs différents.
• Définition de MBeans standards par annotations (@MBean, @ManagedAttribute et @ManagedOperation) et de leur injecter des ressources telles qu'un MBeanServer ou un ObjectName. Ce principe de définition de MBeans par annotations est calqué sur ce que Spring permet actuellement.
• Un nouveau langage de requête permettant d'accéder facilement à tous les MBeans dont les propriétés se conforment à certains prédicats.

JMX 2.0 était initialement prévue pour être intégrée au prochain JDK, l'API avait fait son apparition au sein de la Javadoc des previews du JDK 7 mais restait absent de sa liste de features. Eamonn McManus a clarifié cette situation en annonçant sur son blog que JMX 2.0 ne serait pas intégré au JDK 7 tel qu'initialement prévu, qu'il n'était pas pour autant annulé mais reporté ... au JDK 8. L'officialisation de ce report est une mauvaise nouvelle, car cette nouvelle mouture de JMX serait arrivée à temps pour apporter un renouveau à cette API, qui bien que très puissante, souffre parfois de lourdeurs à l'usage.

Evènements de notre communauté en France et à l'étranger

Retour sur la conférence Jazoon

La semaine dernière se tenait à Zürich la conférence où les Javaistes se rencontrent. Xebia était présent à cette conférence et en a publié des résumés quotidiens :

• Jour 1 : JEE6 et Glassfish v3
• Jour 1 : Groovy
• Jour 1 : Développement mobile
• Jour 1 : Prospective
• Jour 2 : JDK 7
• Jour 2 : DDD et Value Objects
• Jour 2 : Java FX
• Jour 3 : Un arbre est tombé
• Jour 3 : Les secrets des programmeurs Rockstars
• Jour 3 : Hibernate Search

• Trier les résultats par pertinence
• Extraire la quintessence : "le Blog de XEbia" -> "blog xebia"
• Approximation : "xeiba" -> "xebia"
• Recherche phonétique
• Synonymes
• Même famille/racine : "opérer, opération, opérez"

Pertinence

La pertinence est déterminée par le nombre d'occurences trouvées :

• Nombre d'occurences par document pour un mot-clef.
• Nombre d'occurences de nombre de mots-clefs pour un document.

La pertinence dépend aussi des champs dans lesquels on effectue la recherche. On peut "prioriser" certains champs par rapport à d'autres. Par exemple on peut affecter un poids plus important au titre d'un livre qu'à sa description.

Extraire la quintessence

Le moteur de recherche tokenize la "requête" pour découper et récupérer tous les mots, puis il applique des filtres. Il peut notamment mettre tous les mots en minuscules ou retirer les mots trop courants, sans interêt ("le", "un", "de", etc).

Approximation

L'approximation permet de compenser notamment les fautes de frappe.
Une première approche est de mesurer la similarité entre les mots (distance de Levenshtein/d'édition) mais cela est coûteux niveau performance.

L'autre approche est le N-grammes. Cela consiste à découper les mots en morceaux de n caractères puis d'indexer ces morceaux.
Exemple d'utilisation d'un tri-grammes :

• On découpe et indexe "Hibernate" -> [hib, ibe, ber, ern, rna, nat, ate]
• L'utilisateur tape "ybernat" -> [ybe, ber, ern, rna, nat]
• On compare les morceaux en communs : [ber, ern, rna, nat].

Recherche phonétique

Des algorithmes (Soundex, ou plus évolué Metaphone) permettent de calculer des codes phonétiques qui sont stockés dans un index. Mais ce type de recherche n'est pas le plus courant.

Synonymes

La recherche de synonymes se base sur un dictionnaire qui indexe tous les synonymes de chaque mot.
Ce dictionnaire est évidemment propre à chaque domaine métier, chaque application, et c'est pour cela qu'il a une réelle valeur ajoutée car même Google ne peut connaitre votre métier aussi bien que vous.
Pour chaque groupe de synonymes il est conseillé d'avoir un mot de référence, qui sera celui indexé. Ainsi les mots saisis par l'utilisateur sont traduits en mots de référence avant d'être comparés à ceux de l'index.

Même famille

L'approche brutale consiste à indexer toutes les variations d'un mot. Plus subtil, on peut supprimer certains suffixes pour ne garder que la racine.
Il existe ensuite des algorithmes avancés (mais majoritairement pour l'anglais), comme celui de Martin Porter avec son langage Snowball.

En pratique

Si vous voulez savoir comment mettre en pratique ces fonctionnalités avec Hibernate Search, (re)lisez ce hands-on.