Actualité éditeurs / SSII

• SpringSource : sortie par le haut
• Websphere: les derniers seront les premiers ?

Agilité

• Prioriser le Product Backlog
• Leçons de management par la NASA

RIA

• 10 choses à savoir sur Flex
• GraniteDs en version 1.1.0

Le coin de la technique

• JSR-277 : OSGi m’a tuer (Stanley Ho)

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

• Paris JUG : soirée OSGi

Actualité éditeurs / SSII

SpringSource : sortie par le haut

Comme nous l’annoncions succinctement mercredi, SpringSource a revu sa copie concernant sa nouvelle politique de maintenance abandonnant de ce fait les points les plus polémiques de celle-ci, dont sa fameuse règle des trois mois à l’origine des levées de boucliers de la communauté.

Dans son post de mardi dernier, Rod Johnson dévoile donc le nouveau fonctionnement de celle-ci : les releases seront disponibles pour la communauté jusqu’à la sortie d’une nouvelle version majeure. Ainsi, les binaires des versions 2.5.x du cœur du framework continueront d’être publiés tant que Spring 3.0 RC1 n’est pas disponible. SpringSource compte, par ce biais, inciter la communauté open-source à toujours coller aux dernières versions de son framework.

Websphere: les derniers seront les premiers ?

Dernier serveur certifié Java EE 5, Websphere ressort grand vainqueur d’une étude comparative des principaux serveurs d’application du marché, menée par Evans Data Corporation (rapport gratuit, mais enregistrement nécessaire).

Cette étude soulève déjà de nombreuses questions chez les concurrents (comme Rick Sharples, de JBoss), le marketing d’IBM n’allant pas se plaindre d’une si belle vitrine.
Rick émet 3 interrogations majeures :

• Comment comparer des serveurs d’application dont les communautés peuvent varier d’un noyau de type ‘niche’ (SAP) à des super-communautés mondiales (IBM, BEA, RedHat ou Microsoft) ?
• Pourquoi n’arrive t’on pas à corréler les résultats de cette étude avec ceux d’autres études publiques, voire internes, sur JBoss ?
• Pourquoi évalue t’on un serveur aussi confidentiel que Geronimo (lui aussi chez IBM) ?

Pour notre part, nous émettons un certain nombre de réserves :

• L’étude ayant été menée durant l’été 2008, elle ne peut nécessairement pas porter sur WAS 7.0, sorti officiellement en septembre (d’autant plus qu’un des points de l’étude porte sur le support, qui n’est pas assuré pour les versions beta). Cette étude porte donc plus globalement sur ‘les marques’, plutôt que sur les dernières versions des serveurs d’application cités.
• Les consultants Xebia ont l’habitude de travailler avec bon nombre de ces serveurs d’application, et au petit jeu des comparaisons directes (ce qui n’est pas le cas de cette étude), les avis sont loin d’être aussi tranchés.
• La rédaction du rapport est très orientée ‘marketing’, ce qui est étonnant au vu de la population consultée. Il est étonnant de lire des phrases telles que « WebSphere’s users obviously love this product. » venant de développeurs qui n’ont souvent pas le choix de leur serveur d’application (souvent dicté par les achats groupe ou l’exploitant) et qui ont tendance à ne faire que « subir » ses désavantages.

Alors, étude téléguidée par un éditeur ? Enième conflit d’intérêt pour un cabinet d’analyse dont les clients sont les premiers sujets de comparatifs ? La réponse est sûrement plus complexe et on peut tout au plus tirer quelques enseignements de ce travail :

• JBoss joue définitivement dans la cour des grands, et est un concurrent sérieux pour les « grands » serveurs d’application, même sur des applications à grande échelle.
• la communauté s’inquiète du rachat de BEA par Oracle (peut-être est-ce même la raison principale de cette 7ème place).
• Le « petit jeune », Glassfish, qui remporte l’adhésion des développeurs pour sa facilité de mise en oeuvre, n’est pas en reste sur les fonctions principales (performances, scalabilité) et vient titiller les vieux mastodontes.
• La comparaison objective de serveurs d’application, dans un environnement aussi hétéroclite que celui des SI du XXIeme siècle, avec des problématiques variées et complexes, est un exercice dangereux, qui porte rapidement à critique.

Agilité

Prioriser le Product Backlog

En Scrum, il faut ordonner les éléments du Product Backlog pour que l’équipe sache quelles sont les fonctionnalités à implémenter en priorité.
Peter Stevens propose différentes stratégies pour prioriser le Product Backlog, à composer selon le contexte du projet :

• Ensemble minimum de fonctions : faire une liste minimum des fonctions à implémenter pour que le produit soit utilisable et accepté par les utilisateurs
• Valeur métier en premier : se concentrer sur les fonctions à haute valeur ajoutée métier. La valeur métier (typiquement avec un coefficient entre 1 et 100) est fixée par le Product Owner.
• En avoir pour son argent : semblable à la précédente approche, elle se concentre sur les éléments qui ont le meilleur rapport valeur métier/coût.
• Risques techniques en premier : préconisée par RUP, cette approche s’attaque aux points techniques difficiles en premier. Cela peut cependant conduire à un système trop complexe par rapport aux besoins.
• Reporter le risque : s’attaquer aux difficultés en dernier (ou jamais). Préférer les stories bien comprises, tout en investigant les stories plus risquées/coûteuses pour les décomposer.
• Votes des utilisateurs : demandez aux utilisateurs de voter parmi une liste de fonctionnalités potentielles.

Ce dernier point peut être accompli par une analyse de Kano comme le propose Mike Cohn dans sa présentation Prioritizing Your Product Backlog mise en ligne sur InfoQ. Le pdf est également disponible.
Mike Cohn y présente plusieurs techniques de priorisation, plus concrètes mais nécessitant plus de calculs :

• Analyse de Kano : distinguer les thèmes selon 3 types : fonctions obligatoires, linéaires, et attractives. Implémenter toutes les fonctions obligatoires, le plus de linéaires possible et quelques excitateurs pour la satisfaction utilisateur.
• Theme screening : noter les thèmes selon certains critères de sélection, par rapport à un thème de référence.
• Theme scoring : semblable au Theme screening en pondérant les critères de sélection
• Relative weighting : pour chaque thème, calculer le rapport entre sa valeur relative (aux autres thèmes du product backlog) et son coût relatif. Ce rapport donne la priorité du thème.

Ces techniques s’appliquent toutes au niveau thème, car descendre au niveau user story demanderait trop de travail sur un product backlog complet.

Leçons de management par la NASA

Jerry Madden, un ancien employé du Goddard Space Flight Center de la NASA, a collecté « 100 leçons » apprises auprès des managers qu’il a cotoyés.
Marios Alexandrou en a extrait les leçons qui collent le plus avec son expérience des projets web. Parmi les plus marquantes :

• Une réunion de travail devrait durer 5 minutes minimum (moins elle est inutile) et 1 heure maximum (plus c’est un marathon). Au-delà de 6 personnes, elle devrait être réservée au transfert d’information.
• Ne demandez jamais à vos chefs de prendre une décision que vous pouvez prendre vous-même, sauf si un document vous l’interdit.
• Ne supposez jamais que quelqu’un a fait quelque chose, demandez lui. Même le plus évident peut être oublié, surtout en période de stress.
• La documentation ne remplace pas la connaissance. Les documents restent des images statiques dans le temps et sont rapidement dépassés.
• Les projets nécessitent un travail d’équipe pour réussir. Rappelez-vous que la plupart des équipes ont un coach et non un boss, mais le coach doit parfois arbitrer certaines parties.
• Si un chef de projet est l’homme le plus intelligent de l’équipe, c’est qu’il a fait un mauvais travail de recrutement.
• Les principes de gestion sont toujours les mêmes. Seuls les outils changent. Vous devez toujours trouver les bonnes personnes pour faire le travail et rester à l’écart pour qu’ils puissent le faire.

Il est amusant de constater certaines similitudes avec les méthodes agiles. Les individus et leurs connaissances sont plus importants que la documentation. Le coach doit s’appuyer sur une équipe de personnes motivées, intelligentes, et responsables qui n’attendent pas d’ordre d’un patron. Leur collaboration est essentielle à la réussite du projet. Ces ressemblances sont logiques finalement, il s’agit simplement de bon sens.

RIA

10 choses à savoir sur Flex

Les articles recommandant Flex se succèdent. Après l’annonce d’Atos sur son blog Entreprise 2.0 du choix de Flex sur plusieurs projets pour de grands comptes et la « victoire » de Flex lors de notre RIA Contest, c’est au tour de Alaric Cole, l’auteur de « Learning Flex 3″ de lister 10 avantages à l’utilisation de Flex.

Alaric Cole est partie prenante, et on a déjà pu lire sur d’autres blogs les différents points cités, mais l’article a l’avantage de les regrouper :

1. Flex s’apparente aux standards d’une application Web : MXML est un langage de balises comparable à l’HTML, l’ActionScript est l’équivalent du JavaScript. Le tout customisable avec du CSS.
2. Flex = Flash : tout ce qui était possible en Flash l’est en Flex. Flex apporte cependant une couche de structuration/méthodologie par rapport à Flash
3. Une application Flex fonctionne sur tous les navigateurs et tous les OS (Linux 64bit ?). La seule contrainte est d’avoir déployé le plug-in d’exécution.
4. Le framework RIA d’Adobe accepte l’échange de données et propose des interfaces de communication avec plusieurs formats d’échange (SOAP, HTTP, AMF…)
5. Une application Web Flex aura un « Look And Feel » identique quelque soit l’OS client
6. Flex est léger et rapide grâce notamment aux améliorations du futur plug-in Flash 10. Par exemple, la fonctionnalité de « Framework Caching » permet de réduire à 100Ko la taille de l’application à télécharger
7. Les composants de Flex sont nativement construits pour être accessibles (loupe, internationalisation, raccourcis clavier…)
8. Le contenu d’une application Flex peut maintenant être indexé par un moteur de recherche
9. Le SDK Flex est maintenant OpenSource et gratuit mais attention l’IDE Flex Builder est payant.
10. Enfin, il rappelle la facilité d’apprentissage du langage. Pour un habitué de la Javadoc, l’accès au format ASDocs d’Adobe est cependant déroutant les premiers temps.

Même si l’ancienneté de Flex sur le marché, la couverture de déploiement de son plugin d’exécution et la solidité de son distributeur Adobe semblent placer Flex en tête du tournoi RIA, il est bon de rappeler que la compétition ne fait que commencer : 2 outsiders sérieux (Silverlight et JavaFx) vont bientôt s’élancer dans la course ! L’avance prise par Flex pourra t-elle être comblée ?

GraniteDs en version 1.1.0

GraniteDS est un framework opensource équivalent à BlazeDS, simplifiant le développement des communications entre un RIA Flex et un serveur J2EE. Cet article d’InfoQ nous présente les nouvelles fonctionnalités disponibles sur GraniteDS 1.1.0:

• Granite Eclipse Builder : un plugin Eclipse basé sur AS3 Generator permettant de générer le code ActionScript 3 associé aux JavaBeans. Ce plugin génère automatiquement du code lorsqu’un JavaBean est modifié.
• Tide : ce framework fournit des fonctionnalités telles que la mémorisation d’objets dans un contexte qui transite entre la partie cliente et la partie serveur, la pagination des données. Il permet également de gérer le lazy loading des collection en wrappant les collections et en les récupérant dés que c’est nécessaire.
• MXML Web Compiler : une compilation à la volée du code source MXML et ActionScript 3 sur le serveur d’application.

Avec cette nouvelle version, GraniteDS se positionne comme un concurrent sérieux de BlazeDS. La génération des JavaBeans, la gestion du lazy loading et la compilation à la volée sont des points forts qui séduiront très vite les développeurs. Cette nouvelle approche ne peut que faciliter et améliorer le développement d’applications Flex.

Le coin de la technique

JSR-277 : OSGi m’a tuer (Stanley Ho)

Stanley Ho a annoncé son départ de Sun Microsystems. Par la même occasion, il laisse les clés de la JSR-277 dont il était à la tête. C’est donc Alex Buckley qui reprend le flambeau, il était déjà responsable de la petite sœur, la JSR-294 : les superpackages.

Nous sommes en droit de nous demander si la création du prototype permettant l’interopérabilité entre Java Module System et OSGi qu’a amorcé Sun ces derniers mois a quelque chose à voir avec ce départ. Quoi qu’il en soit, le tournant est définitivement engagé pour le futur de Java Module System.

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

Paris JUG : soirée OSGi

Dernière piqûre de rappel pour la soirée OSGi de ce mardi 14 octobre au Paris JUG.

• Le programme est disponible ici : première partie ‘introduction à OSGi’, seconde partie : ‘OSGi appliqué’
• Les inscriptions sont gratuites et ouvertes à tous, enregistrez-vous ici
• La soirée aura lieu à l’ISEP, dont voici le plan d’accès

Nous vous y attendons nombreux.

Actualité éditeurs / SSII

• Spring Source : les VC prennent le contrôle
• JBoss certifié Java EE 5 : un anachronisme corrigé ...
• ... tandis que Websphere 7 sera le dernier grand sur la ligne d'arrivée

Agilité

• Le Scrum meeting, story par story ?

RIA

• Microsoft et Nokia adoptent jQuery

Le coin de la technique

• Les spécifications REST se terminent
• JVM Wish List vue par Terracotta
• Principes pour le design d'une API
• David Syer communique sur Spring Batch

Actualité éditeurs / SSII

Spring Source : les VC prennent le contrôle

Les semaines se suivent et ne se ressemblent pas chez Spring Source. Après le tumultueux revirement de stratégie Open Source il y a dix jours (cf. Nouvelle politique de maintenance de Spring : La très périlleuse route de monétisation de l'open source), Benchmark Capital, le principal fond d'investissement de Spring Source, prend le contrôle opérationnel de la société en nommant Rob Bearden President and Chief Operations Officer (COO). Rod Johnson conserve le titre de CEO.

C'est un véritable tournant dans la vie de Spring Source qui était jusqu'à présent gouvernée par son fondateur Rod Johnson et est aujourd'hui confrontée aux défis de la rentabilité et de la croissance.

Nous noterons au passage un clin d'oeil de l'histoire : Rob Bearden, avant de rejoindre Benchmark Capital, a été COO de JBoss. Le monde de l'Open source est petit, espérons que les relations conflictuelles entre les camps JBoss et Spring Source s'adoucissent

Les interrogations sont nombreuses : quelle place trouvera Rod Johnson dans cette nouvelle organisation ? Quelle stratégie Open source va adopter Rob Bearden ? Entérinera-t-il la nouvelle politique de commercialisation des releases post trois mois qui suscite encore une polémique très vive ?

Quelques liens :

• The Server Side : What will be next with SpringSource?
• Communiqué officiel : SpringSource Names President and Chief Operating Officer
• The Register : SpringSource VC investor takes COO role

JBoss certifié Java EE 5 : un anachronisme corrigé ...

L'anachronisme que personne ne comprenait est enfin corrigé. JBoss Application Server, précurseur de Java EE 5 avec le support de JPA dans Hibernate et la Web Application qui jouait le rôle d'un conteneur d'EJB 3 est enfin certifié Java EE 5. Sacha Labourey, JBoss, annonce dans JBoss AS is now EE5 certified! que la version release sera disponible dans les semaines à venir. Il n'en reste pas moins que JBoss AS 5 est une refonte sur le fond du serveur d'application (nouveau messaging, clustering, etc) qui a duré plus de trois ans (cf InfoQ : Releasing JBoss AS 5: Q&A with Project Lead Dimitris Andreadis) et qu'on peut s'attendre à une phase de stabilisation de la nouvelle stack JBoss.

... tandis que Websphere 7 sera le dernier grand sur la ligne d'arrivée

IBM nous rappelle avec Websphere que les parts de marché sont parfois décorrélées de l'implémentation des dernières spécifications. Websphere 7 sera le dernier grand serveur Java EE a être certifié Java EE 5.

La version d'évaluation est déjà disponible sur DeveloperWorks ; des blogs (Websphere Community et Websphere and Messagin) relaient la communication institutionnelle.

Agilité

Le Scrum meeting, story par story ?

Les daily standup meetings se déroulent habituellement personne par personne, c'est-à-dire que chaque membre de l'équipe répond aux 3 questions l'un après l'autre. Le défaut de cette méthode selon Mike Cohn est qu'elle ne permet pas toujours de voir les problèmes sur les stories dont personne ne s'occupe puisque personne n'en parle.
Il suggère la possibilité d'attaquer le standup story par story, mais on perd alors en visibilité sur ce que fait chaque personne. Face à ce dilemme, plusieurs solutions sont possibles :

• L'équipe s'engage t-elle sur trop d'items par sprint ? Mike préconise une moyenne de 1 à 1,5 story / personne / sprint. Attention, cela ne veut absolument pas dire qu'une story doit être gérée par une seule personne !
• Faire le standup devant le tableau des tâches, afin que chaque personne puisse pointer les items sur lesquels elle travaille.
• Désigner des "story owners" : pour chaque story, une personne de l'équipe est responsable de son avancement. Cette personne n'est pas forcément le développeur principal de la story.
• Regarder la taille de l'équipe : selon ses observations la taille idéale d'une équipe se situe entre 5-7 personnes.

La plupart des équipes font leur standup par personne, mais certaines équipes peuvent se heurter à un manque de visibilité sur certaines stories. Cette vision "story par story" peut répondre à leurs attentes.

RIA

Microsoft et Nokia adoptent jQuery

À part GWT avec Google, un des reproches que l'on peut faire aux librairies JavaScript/AJAX est leur absence de support par un grand éditeur. Cet état de fait pourrait bien changer pour la librairie jQuery, une de nos librairies favorites, que l'on conseille et rencontre de plus en plus fréquemment chez nos clients. jQuery annonce sur son blog l'adoption par Microsoft et Nokia du framework, et son intégration dans leur plateforme de développement officielle respective.
jQuery sera donc distribué avec Visual Studio, et sera présent dans tous les nouveaux téléphones de Nokia qui utiliseront le moteur de rendu maison Web Runtime.
Les bénéfices pour jQuery et ses utilisateurs sont multiples : la reconnaissance de la librairie comme parmi les plus populaires, et son amélioration via la soumission de patchs et de tests. Excellente nouvelle donc !

Le coin de la technique

Les spécifications REST se terminent

Vous en entendrez certainement parler prochainement à l'occasion de Spring 3.0, les spécifications de la JSR-311 : Java API for RESTful Web Service (JAX-RS) ont été approuvées quasi unanimement (15 pour, 0 contre, 1 non votant) par l'executive comitee.

JAX-RS est une API permettant l'implémentation de Web Services REST, son fonctionnement est simple :

• on rajoute des annotations sur des classes et des méthodes pour décrire les services à exposer et la manière de les exposer
• le choix du service s'effectue en fonction des URL / Content type / Headers et type de requête HTTP

REST étant à la mode, plusieurs framework existent déjà dont :

• Jersey, l'implémentation de référence pour JAX-RS développée par Sun
• Restlet, le framework du moment le plus utilisé pour les applications REST
• CXF RESTful Services, l'implémentation JAX-RS du projet Apache CXF
• RESTeasy, la version JBoss

Une interview des specs leads Marc Hadley et Paul Sandoz est disponible sur InfoQ. Une des questions intéressantes porte sur l'influence de la JSR311 sur les spécifications de Servlet. Cela nous rappelle que, même si les API REST et les Servlets ont des approches complètement différentes, ces deux technologies doivent pouvoir cohabiter et travailler ensemble.

JVM Wish List vue par Terracotta

Cet article présente une liste d'améliorations JVM espérées vues par un spécialiste Terracotta. S'il est vrai que cet outil aborde des problématiques peu communes (clustering de JVM), certaines de ces idées pourraient être utiles pour tout autre framework utilisant l'instrumentalisation de code.

Voici les idées proposées par Steeve Haris dans son article regroupées par domaines, elles permettent de :

• Simplifier grandement le code de ce genre de framework en évitant d'avoir à développer des surcouches logicielles simulant certaines de ces fonctionnalités
• Permettre de créer des proxy d'objets niveau JVM : cela faciliterait le maintien de la heap virtuelle de Terracotta
• Pouvoir associer des métadatas à un objet : cela permettrait d'affiner les choix du memory manager de Terracotta
• Faciliter le développement de tricks en améliorant le _Hot swapping_
• Optimiser le nombre d'objets à instrumentaliser
• Permette d'instrumenter des tableaux sans avoir besoin de passer par les classes les utilisant
• Permettre le remplacement de méthodes natives : actuellement si l'on veut modifier le comportement d'une méthode native, nous somme obligé d'instrumenter tous les objets appelant celle-ci.
• Adapter la JVM aux architectures d'aujourd'hui
• La taille des listes et des collections est définie par un int. Les architectures 64 bits nous permettant d'ajouter de plus en plus de mémoire, il se peut que cette taille devienne insuffisante dans certaines utilisations.

Principes pour le design d'une API

Joshua Bloch (Google), auteur de Effective Java, énumère un ensemble de principes clés afin de réussir la conception et la réalisation d'une API : Bumper-Sticker API Design.

Une API n'est pas seulement mise en place dans les frameworks mais aussi dans des applications à différents niveaux :

• la couche d'accès aux données
• la couche service

La volonté d'une API est de réaliser un module cadré au fonctionnement clair. Le fonctionnement interne du module est caché derrière un contrat d'utilisation (qui ne repose pas nécessairement uniquement sur des interfaces Java). Le terme d'utilisabilité de l'API peut être employé.

L'utilisabilité d'une API peut être décrite avec les spécificités suivantes :

• contrat d'utilisation simple et explicité, cela passe par le nommage des éléments (classe, méthode, argument, ...).
• l'intégration aux cas d'utilisation doit être naturelle. Pour que ce soit le plus naturel possible, on peut même envisager de d'abord coder les cas d'utilisation avec l'appel à l'API et ensuite coder l'implémentation de l'API.
• l'implémentation de l'API doit être indépendante du contexte d'appel

Le développement d'API pose le problème de la gestion des versions. A partir du moment où elle est exposée, une API doit répondre de la même façon à tous les appels, quel que soit le client sollicitant le service. Il est vital de respecter les principes de l'IoC Inversion of Control, et ne pas enrichir chaque version d'un ou plusieurs comportements spécifiques :

Des principes qui font généralement débats sont aussi présentés :

• Faire peu de documentation, les noms des classes/méthodes doivent être explicites
• Ne pas remonter de CheckException que des RuntimeException

Il est vrai que la principale difficulté d'une API est de bien faire dès la première version. La moindre modification du contrat d'utilisation de l'API entraînera des régressions chez les clients de l'API.

C'est pour cette raison qu'il faut tenter de faire un premier jet aussi bref et concis que possible, et de ne traiter la multiplicité des cas qu'au fur et à mesure de leur apparition, dans des versions ultérieures.

Pour conclure, on reprendra la phrase de Joshua Bloch : le design d'API est un art, pas une science exacte.

N'hésitez pas à visionner le vidcast associé à cet article.

David Syer communique sur Spring Batch

Nous vous l'annoncions avant l'été, David Syer, le leader technique de Spring Batch, a entamé sa "tournée promotionnelle".

À travers ce vidcast, capté au QCon de Londres et relayé par InfoQ (ou bien via le support de présentation), il revient sur :

• les patterns de batch et leur utilisation
• un survol des concepts de SpringBatch
• une étude de cas
• l'avenir de ce produit

D'autre part, dans une autre vidéo publiée sur TV4it, Olivier Rachon, Senior Manager chez Accenture, nous en dit plus quant à l'utilisation de ce récent framework : 5 projets en production, des 10aines en cours de développement.

Pour information, la version 1.1.2 est disponible et les premiers tests que nous avons effectués, dans le cadre d'un XKE, nous ont paru très convaincants. Nous devrions publier prochainement notre retour d'expérience sur ce framework.

Le coin de la technique

• invokedynamic vu de l'intérieur
• Concurrency : past and present
• Tuning des JVM Websphere 6.1
• Performance d'affichage d'une page Web

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

• Refactoring itératif de conférences : JavaPolis, Javoxx et DeVox

Le coin de la technique

invokedynamic vu de l'intérieur

Dans cet article, Charles Nutter, JRuby Core Developper nous présente pourquoi il est nécessaire de mettre à jour le bytecode invokedynamic.
Java nous oblige à typer chaque variable et chaque méthode doit définir une signature statique dont les types sont connus avant le Runtime : Java est un langage 'statiquement' typé. Si ce typage fort est une des forces du langage, comment la JVM peut-elle supporter des langages dynamiques ? La rigidité de Java provient, plus de son langage que de son bytecode. C'est ainsi que des langages comme Groovy permettent d'enfreindre certaines règles, par exemple : ne pas définir de types aux variables. Ce n'est pas pour autant que le bytecode va tout nous permettre, certaines règles sont incassables dont celles qui s'appliquent aux invocations de méthodes :

• Les invocations sont statiquement typées.
• Les invocations doivent s'effectuer sur des méthodes Java. Il est impossible de remplacer un appel à une méthode par un morceau de code interprété.

À l'origine, la JSR-292 a proposé la mise en place d'un nouveau code invokedynamic permettant l'invocation de méthodes sans signatures typées statiquement, mais rien n'avait été prévu pour modifier dynamiquement la logique d'invocation de la JVM.

Concurrency : past and present

Brian Goetz, auteur du livre 'Java Concurrency In Practice', a publié sur InfoQ une vidéo enregistrée lors du QCon 2007 : Concurrency : Past and Present.
Pourquoi est-il plus difficile de développer des applications multithreadées que de parler en lisant son journal ?
Dans cette présentation, Brian tente de répondre à cette question en revenant sur les principales difficultés de la programmation concurrente. Sujet que nous avions également abordé lors d'un article publié cet été sur le sujet : "programmation concurrente : notions fondamentales". Pour illustrer ces problèmes, Brian revient sur l'histoire de la programmation concurrente et ses différentes approches, avant de donner ses recommandations. À la fin de la vidéo, il présente également les fonctionnalités offertes par d'autres langages comme ErLang et Scala.

Tuning des JVM Websphere 6.1

Giribabu Paramkusham et Ajay Bhalodia, WebSphere Application Server Technical Support, présentent dans JVM Performance Tuning with respect to Garbage Collection(GC) policies for WebSphere Application Server V6.1 part 1 (pdf) les points clef du tuning des JVM pour Websphere. Nous retiendrons :

• Les JVM IBM proposent quatre stratégies de garbage collections :
       - -Xgcpolicy:optthruput pour minimiser le temps global d'exécution (batch, ...).
       - -Xgcpolicy:optavgpause pour minimiser la durée de chaque pause.
       - -Xgcpolicy:gencon destiné aux applications web. L'algorithme Générationnel Concurrent communément utilisé dans les JVM Sun est optimisé pour les objets à courte durée de vie.
       - -Xgcpolicy:subpools pour les serveurs à grand nombre de processeurs (>16).
• A la différence de l'implémentation GenCon de Sun qui comprend trois zones (Young, Tenurd et Permanent), celle d'IBM n'en comporte que deux (Young et Old)
• L'option -verbose:gc est activable en production avec un impact négligeable sur les performances et l'option moins connue -Xverbosegclog permet de préciser un fichier de sortie en mode rolling file . Nous noterons que les informations de GC sont désormais formattées en XML ce qui facilitera la manipulation avec des outils.
• Indépendamment des limites techniques liées au système d'exploitation, les JVM IBM sont optimisées pour utiliser des heap le plus souvent inférieures à 2 GB :

source IBM

• L'utilisation de JVM 64 bits supprime les limites de taille de heap mais pénalisent les performances (plus de données manipulées) et la consommation mémoire (des pointeurs sur 64bits plutôt que 32bits accroissent de 30% à 50% la mémoire consommée)
• La JVM 6 d'IBM réduit les dégradations de performances et de consommation mémoire en 64bits grâce à l'introduction de "pointeurs compressés"

Performance d'affichage d'une page Web

Hayes Potter, nous présente dans Speed up your website, quick! des règles structurantes afin d'améliorer les performances d'affichage d'une page Web :

• Compression des ressources statiques (images, fichiers flashs, scripts, ...).
• Mettre en place une politique d'expiration des ressources statiques .
• Mettre les styles CSS en haut de la page HTML tandis qu'il faut mettre les fichiers Javascript en bas de la page.
• Limiter les requêtes http://request vers d'autres domaines. En effet à chaque requête vers un autre domaine, pendant le chargement de la page, une résolution DNS est effectué (accès réseaux supplémentaires).

Dans le même esprit, Yahoo a mis à dispositon de la communauté des développeurs Web un ensemble de règles : Exceptional Performances.
Il y a 34 Best Pratices répartis dans 7 domaines différents :

• Contenu
• Serveur
• Cookie
• CSS
• Javascript
• Image
• Mobile

Voici les règles les plus marquantes :

• Externaliser les fichiers CSS et Javascripts de la page HTML.
• Réduire la taille des fichiers Javascripts en éliminant les caractères superflus (espace, variable à rallonge, ...). Cela peut être assisté par des outils tel que JSMin et YUI Compressor. L'idéal c'est que les développeurs des pages gardent des fichiers Javascripts lisibles et maintenables puis au déploiement de ces pages, passer une moulinette sur les fichiers Javascripts afin d'épurer les caractères superflus.
• Eviter la duplication des importations du même script, par exemple IE retéléchargera plusieurs le fichier bien que c'est la même ressource.
• Utiliser une requête HTTP GET pour les requêtes AJAX.
• Rassembler l'ensemble de vos images (pour les gestions des boutons par exemple) en une seule image et en faire un sprite avec CSS. Cette tache peut être assister par les outils CSS Sprites et Website Performance CSS Sprite Generator.
• Limiter l'utilisation des iframe.

Références :

• Yahoo! New Performance Best Practices Now Available (Mars 2008), excellente présentation de Stoyan Stefanox, développeur Yahoo, qui reprend point par point toutes ces Best Pratices

Voici une liste d'outils facilitant la mise en oeuvre et la vérification de ces points :

• YSlow, outil Yahoo aidant à la vérification de ces best pratices
• Fiddler, debugger HTTP
• IBM Page Detailler, décrire le déroulement des fichiers téléchargés pour l'affichage d'une page
• Firebug (que pour firefox)
• JSMin, minimiseur JavaScript
• YUI Compressor, minimiseur Javascript
• CSS Sprites, générateur de sprite CSS
• Website Performance CSS Sprite Generator, générateur de sprite CSS

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

Refactoring itératif de conférences : JavaPolis, Javoxx et DeVox

Terminons cette revue de presse par la petite histoire belge de la semaine. L'un des plus gros événements Java au monde JavaPolis vient de changer de nom pour la seconde fois cette année. Renommé Javoox en début d'année, il semblerait que cet ancien nouveau nom soit encore trop proche de « Java » pour Sun. Avec ce nouveau nom : DeVoxx, le BeJug (porteur de l'événement) continue le bras de fer avec Sun en osant mettre un 'V' en 3e caractère de leur nouveau nom ... tout comme dans 'jaVa' ... La newsletter de DeVoxx nous explique que ce nouveau changement de nom est dû à une volonté de rester un événement Java indépendant.

• Site officiel du BeJug
• Site officiel du DeVoxx
• Consultez la liste des intervenants à DeVoxx 2008

Actualité éditeurs / SSII

• MySQL by Sun : Revirement de stratégie open source ? Choquant ?
• Superpackages (JSR-294) vs. OSGI : Episode n° 34291567....

Agilité

• User stories "En tant que ... je veux ..."

Le coin de la technique

• De la sérialisation au parallélisme, une évolution incarnée par java.util.concurrent
• Innovation autour de JPA : JBoss Hibernate confirme son domination avec Envers
• Cas d'utilisation des grilles Java avec WebSphere eXtreme Scale/ ObjectGrid
• JSR-311 JAX-RS REST une histoire de RESTaurant

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

• XKE, le programme de la session de mai

Actualité éditeurs / SSII

MySQL by Sun : Revirement de stratégie open source ? Choquant ?

Slashdot essaie de nous emmener sur une polémique "Sun gâche MySQL" avec Sun May Begin Close Sourcing MySQL Features à l'occasion de l'annonce par l'éditeur de fonctionnalités (online backup, etc) qui seront uniquement disponibles dans la version payante MySQL Enterprise. Au delà de l'insinuation peu crédible quand on se rappelle que l'essentiel du catalogue de Sun est disponible gratuitement, on retrouve le défi aujourd'hui classique de la monétisation de l'Open Source. Le rachat de MySQL par Sun change complétement le modèle économique de l'éditeur de base de données.

Hier, la startup MySQL, financée par des fonds de capital risque, se permettait d'être déficitaire car les candidats au rachat (Oracle puis finalement Sun) ne valorisaient pas MySQL Inc sur ses revenus mais sur les parts de marché de sa base de données. La stratégie a magnifiquement porté ses fruits puisque MySQL Inc s'est vendue un milliard de dollars à Sun, félicitations au management.

Aujourd'hui, MySQL est vraisemblablement devenue une division 'classique' de Sun et doit donc devenir rentable. L'équation de la rentabilité de l'open source est complexe, Red Hat et JBoss by Red Hat ont été des pionniers sur ce chemin, souhaitons à MySql by Sun de trouver lui aussi son modèle.

TSS : MySQL to get new features in Enterprise version

Modification du billet le 29 Avril 2008 : Jonathan Schwartz est finalement revenu en arrière et a annoncé que tous les produits que Sun distribue, sans exception, sont proposés gratuitement en licence Open source à la communauté. Pour plus de détails sur cette histoire, nous vous recommandons la série de The 451 Group : MySQL’s business model in a state of flux, Finding the right balance - MySQL’s changing development model et Jonathan Schwartz has the last word on MySQL

Superpackages (JSR-294) vs. OSGI : Episode n° 34291567....

La guerre continue entre les partisans de OSGI et ceux des JSR de SuperPackage et de JAM. Cependant, l'attaque vient cette fois-ci d'Alex Buckley de chez Sun.

Il explique dans son email les inconvénients qu'il voit dans l'implémentation actuelle des superpackages[1]. En substance, il propose d'introduire à la place un nouvel 'access modifier' (module).

Peter Kriens de l'OSGi Alliance semble plutôt emballé par cette proposition.

[1] Pour mémoire, nous avons publié en février dernier un article présentant les superpackages

Agilité

User stories "En tant que ... je veux ..."

Mike Cohn nous rappelle les 3 raisons pour lesquelles il préconise de décomposer les user stories sous forme de phrase "En tant que <role>, je veux <but>, pour que <raison>" (la raison est optionnelle) :

• L'emploi de la 1ère personne du singulier aide les développeurs à s'identifier à l'utilisateur
• La structure de la phrase - représentée par 3 colonnes dans le Product backlog - aide le Product Owner à comprendre et prioriser les user stories
• Pour ne pas rajouter de bruit dans la description des user stories, il suffit de nommer les colonnes du Product backlog "En tant que ...", "je veux ...", "pour que ..." et le backlog devient intuitif à lire.

Le coin de la technique

De la sérialisation au parallélisme, une évolution incarnée par java.util.concurrent

La programmation multi-threadée en java a évoluée : anciennement on utilisait la sérialisation incarnée par synchronized, désormais on peut faire du parallélisme avec l'introduction des API java.util.concurrent en Java 5.

Sharadjava nous présente dans sa Java Concurrency Series les différents aspects de cette nouvelle librairie :

• Simple Executor example pour la parallélisation des tâches.
• Barrier pour l'attente entre tâches (on n'oubliera pas sur ce sujet le CountDownLatch).
• Meaning of volatile pour la visibilité inter-threads des valeurs des variables.

Innovation autour de JPA : JBoss Hibernate confirme son domination avec Envers

Après l'intégration de la recherche full text Lucene [1] et le support du Database Sharding, Hibernate confirme sa domination de l'innovation autour de JPA en ouvrant le chantier du versionnage des données. Cette problématique, bien que récurrente et accentuée par les nouvelles contraintes réglementaires (Sarbane & Oaxley, etc), restait largement ignorées par nos frameworks et nos très chers design patterns. Seul Martin Fowler nous éclairait sur ce sujet délicat avec Patterns for things that change with time.

JBoss comble aujourd'hui ce vide en lançant Envers, une extension d'Hibernate qui versionne les données persistantes selon un pattern similaire au Temporal Object de Martin Fowler. Envers n'est qu'en version preview mais le projet est très prometteur et déjà une source d'inspiration pour les projets qui n'ont pas le temps d'attendre la première version stable.

On notera au passage qu'Envers préfère l'API standard JPA EntityManager à l'historique Session Hibernate ; on peut y voir un signe que le temps est venu pour les équipes projets de privilégier les standards JPA aux API historiques Hibernate.

Exemple d'entité persistante versionnée avec JBoss Envers

[1] cf notre billet Introduction à Hibernate Search (Googling your Persistent Domain Model)

Cas d'utilisation des grilles Java avec WebSphere eXtreme Scale/ ObjectGrid

Billy Newport présente dans Video: Introduction to WebSphere eXtreme Scale/ObjectGrid with patterns and use cases les scénarios typiques d'utilisation de la grille Java d'IBM :

• Cache de proximité classique : la grille sert de Map distribuée ; l'application métier gère les données (chargement depuis les backends, mise en cache et sauvegarde des modifications dans les backends).
• Cache de proximité avec "Loader synchrone" dans la grille : l'application métier se limite à demander des données à la grille et à les modifier ; la grille, grâce à un Loader, s'occupe de charger les données depuis les backends et sauvegarde en synchrone les données modifiées dans les backends.
• Cache de proximité avec un "Loader à écriture différée" dans la grille : similaire au scénario précédent mais la sauvegarde des modifications dans les backends est asynchrone.
• Cache collocalisé : l'application et la grille s'éxécutent dans les même JVM, chaque JVM héberge un noeud du cluster de l'application et un noeud de la grille. Ce scénario est typique de la mise en cache des sessions HTTP.

On notera que les architectures de type Map/Reduce, qui nécessitent une conception radicalement différente, ne semblent pas encore très répandues.

JSR-311 JAX-RS REST une histoire de RESTaurant

Dans cet article, Nicolas Martignole nous présente l'architecture REST (Representational State Transfer) et JSR 311: JAX-RS: The Java API for RESTful Web Services. L'objectif de cette JSR est de faciliter la programmation d'applications REST en Java.
La première partie est consacrée à une introduction de REST (définition d'une ressource, lecture, création, mise à jour, suppression d'une ressource, Services Webs RESTfull).
La deuxième partie nous présente quelques détails sur l'implémentation JAX-RS avec Java.

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

XKE, le programme de la session de mai

Le prochain XKE (Xebia Knowledge Exchange) aura lieu le mardi 6 Mai 2008. Les sujets suivants seront abordés :

• Sessions Pratiques
  • Terracotta, the Network Attached Memory (NAM)
  • java.util.concurrent, concours de developpement

• Technique
  • Java et la Cryptographie

• Architecture
  • Retour sur l'architecture de l'un des plus grand site de ecommerce de France
  • Tests unitaires avec les librairies de Mock

• Xebia Hollande
  • Intervention du CTO de Xebia Hollande

Comme nous l'annoncions, les XKE sont ouverts à l'ensemble des personnes à l'écoute du marché de l'emploi autour des technologies Java/J2EE. Si vous êtes l'une d'entre elles , n'hésitez pas à contacter Mélanie Bacrot pour vous inscrire.

Actualité éditeurs / SSII

• Google App Engine, écrivez vos propres applications Google
• Polémique : Gartner Group nous révèle que Windows Vista s’écroule sous son propre poids

Le coin de la technique

• Polémique : Java est en train de perdre la bataille du web moderne
• Java EE Next Generations, les prédictions de Rod Johnson
• Sortie de Maven 2.0.9
• Camel 1.3 : les lightweight ESB progressent
• Netcraft Web Survey : Jetty progresse alors que Tomcat stagne
• IBM ObjectGrid est mort ! Longue vie à Websphere eXtreme Scale !
• Java Web Frameworks Survey

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

• Kirk Pepperdine au Paris JUG

Actualité éditeurs / SSII

Google App Engine, écrivez vos propres applications Google

Google a annoncé la semaine passée la mise à disposition d'une plateforme d'hébergement pour applications Web, Google App Engine. La plateforme est pour l'instant en preview release, seuls 10 000 développeurs on pu s'enregistrer pour y accéder.

App Engine met à disposition des développeurs (pour l'instant gratuitement, mais le service sera bientôt payant) les outils utilisés par Google pour ses propres applications :

• Stockage de données avec BigTable et Google File System (GFS)
• Scalabilité et répartition de charge
• APIs Google, pour gérer l'authentification, envoyer des mails, et dialoguer avec le système de stockage de données
• Ainsi qu'un environnement de développement local

Les développements sont pour l'instant effectués en Python, mais d'autres langages devraient prochainement être supportés. Si vous souhaitez promouvoir votre langage favori, c'est par ici que ça se passe (la demande de support de Java est actuellement en tête devant celles de Ruby et PHP).

Depuis la mise à disposition de ses services Amazon Simple Storage Service (S3), Amazon Elastic Cloud (EC2 - nuage de serveurs), et SimpleDB (base de données), nous savions que ce n'était qu'une question de mois avant de voir la riposte de Google.
Mais les services de Google et Amazon ne sont pas en concurrence frontale. Là où Amazon met à disposition des briques logicielles, Google met à disposition un environnement complet. On pourrait imaginer une application utilisant l'App Engine de Google en façade d'un nuage (EC2) pour le traitement par batchs.
A quand la réponse de Microsoft?

Quelques articles qui nous ont paru intéressants sur le sujet

• ZDNet : Google announces App Engine: Should Amazon worry?
• BusinessWeek : Google App Engine Goes Up Against Amazon, But That's Not the Point
• BioloGeek : Google App Engine - avantages et inconvénients

Polémique : Gartner Group nous révèle que Windows Vista s'écroule sous son propre poids

Gartner Group nous annonce dans Windows collapsing under its own weight; Radical change needed que Windows 7 sera radicalement différent de Vista, ce sera le premier système d'exploitation modulaire de Microsoft.

Scoop ? Pas vraiment, Gartner nous l'avait déjà annoncé en Février 2007 dans Is Vista the last monolithic release?. En revanche, la nouvelle annonce nous dévoile quelques détails sur Windows 7.

Le coin de la technique

Polémique : Java est en train de perdre la bataille du web moderne

TV4IT nous avait invité à participer à son débat Java est mort, vive Java ? (part 2, part 3).
The Server Side relance le débat cette semaine avec Java is losing the battle for the modern web .... Derrière ce titre bien trouvé de guerre moderne, comme d'habitude, Java se ferait sortir du monde des applications web par des architectures LAMP sur des moteurs en C ; même la JVM ne trouve pas grâce aux yeux des cassandres.

Rien de nouveau dans les polémiques millénaristes si ce n'est un avis pessimiste sur l'avenir du prochainement disponible JavaFX face au prometteur Microsoft Silverlight et à l'omniprésent Adobe Flex. Comment JavaFX arrivera-t-il à prendre des parts de marché aux solutions d'Adobe et de Microsoft ? Quelle promesse de valeur ajoutée convaincra les clients de changer de technologie ?

Java EE Next Generations, les prédictions de Rod Johnson

Rod Johnson nous livre dans The Biggest Loser's Next Contestant: Java Bloatware sa vision des prochains serveurs d'applications Java.

C'est l'occasion de comprendre la ligne directrice du framework Spring et en particulier de Spring Dynamic Modules for OSGi(tm) Service Platforms, Spring Integration et Tomcat (récemment rapproché de Spring par le rachat de Covalent).

Nous passerons les habituelles piques contre les serveurs d'applications Java EE qualifiés cette fois de "morbidly obese legacy platforms". Au delà de ces critiques lassantes, nous retiendrons :

• L'avenir de Java EE ne passera plus seulement par les spécifications du JCP mais aussi par celles d'organismes (cf OSGI, SCA, etc.)
• Les serveurs d'applications de demain seront modulaires et beaucoup plus compacts
• Les ESB et les serveurs d'applications vont converger
• Ces évolutions augurent un renouveau de la compétition sur la marché des serveurs d'applications
• Spring se positionne avec sa stack associée au serveur Tomcat dont on peut s'attendre une évolution rapide (OSGI-fication ?)

Sortie de Maven 2.0.9

La dernière version de Maven est disponible, voici les points les plus innovants :

• MNG-3395 : le super pom 2.0.9 contient désormais les versions par défaut pour les plugins de base de Maven. Cette fonctionnalité était grandement attendue, elle devrait résoudre les problèmes de stabilité rencontrés sur les projets qui ne fixent pas dans leur pom parent les versions des plugins, puisque dans ce cas les plugins étaient mis à jour automatiquement dès leur mise en ligne sur le repository. Le travail effectué par Don Brown avec sa branche maven-db a en partie payé!
• MNG-1412 et MNG-3111 : l'ordre des dépendances dans les fichiers classpath générés est désormais déterminé par l'ordre de déclaration dans le pom, les dépendances héritées étant ajoutées à la fin.
• MNG-3415 : une erreur lors du téléchargement d'un artefact ne devrait plus corrompre les métadonnées du repository local. On ne devrait plus avoir besoin de supprimer une partie du repository local dans ce cas.
• Un projet peut désormais importer les dépendances de plusieurs projets grâce au scope "import". Sur un gros projet multi-modules c'était quasiment impossible, puisqu'un module ne peut hériter que d'un seul parent. Bien évidemment si on utilise cette fonctionnalité Maven 2.0.9 devient obligatoire pour builder le projet.

A noter que les 2 premiers points peuvent changer le comportement de votre build, attention aux risques de régression! La liste complète des corrections et améliorations est en ligne.

Camel 1.3 : les lightweight ESB progressent

James Strachan nous présente les nouveautés d'Apache Camel 1.3, le prédécesseur du toujours pas releasé Spring Integration dans le domaine des lightweight esb [1].
On remarquera l'amélioration de la testabilité, la meilleure intégration aux POJOs et le support de Microsoft Message Queuing (MSMQ) et d'AMQP.

Si cette release est une bonne nouvelle pour les utilisateurs des Enterprise Integration Patterns, elle est en revanche une source de confusion pour les utilisateurs d'Apache ServiceMix 3, le conteneur JBI également inclus dans la stack IONA FUSE, dont la valeur ajoutée par rapport à Camel est aujourd'hui difficile à trouver. La présentation du futur ServiceMix 4, qui intégrera OSGI, CXF et Camel, aidera les utilisateurs surpris à comprendre comment s'articulera la suite ActiveMQ-Camel-CXF-ServiceMix.

[1] cf. Xebia Blog : Spring Integration - L'avènement des 'lightweight ESB' ?

Netcraft Web Survey : Jetty progresse alors que Tomcat stagne

Alors que LightHttpd empiète poliment sur les plates-bandes de Apache Http Server avec seulement 2% des parts de marché de son aîné, le conteneur de Servlets open source Jetty rivalise sans complexe avec le très établi mais stagnant Apache Tomcat : le nombre de serveurs Jetty représente 80% de celui de serveurs Tomcat (cf webtide blog: Jetty has 80% of Tomcats public servers).

Comment Jetty a-t-il rattrapé Tomcat aussi vite ? Les innovations de Jetty sont certes intéressantes (OSGI, Ajax Comet Push, etc) mais il faut surtout voir l'attention que Jetty porte à sa communauté de développeurs en proposant un produit très léger et facile à intégrer alors que Tomcat s'est quelque peu endormi sur ses lauriers. Espérons que le récent rachat de Covalent par Spring Source redynamisera la communauté Tomcat.

Source : Webtide blog : Jetty Improves in Netcraft survey

IBM ObjectGrid est mort ! Longue vie à Websphere eXtreme Scale !

Billy Newport nous annonce que la grille de données qu'il a supervisée, IBM ObjectGrid, s'appellera dorénavant Websphere eXtreme Scale

Simple détail de marketing ou signe de "Big Is Beautiful" chez IBM ? Hormis ses qualités qui font d'ObjectGrid une grille de données de tout premier plan [1], ObjectGrid se singularisait dans le portfolio Java d'IBM par une grande indépendance à la stack Websphere (les 6 petits Mo du client ObjectGrid s'exécutent indépendamment de Websphere, même sur une JVM Sun) et par un format de documentation très novateur avec un wiki Confluence plutôt qu'un classique Infocenter.

Billy Newport avait été visionnaire en prédisant dès juillet 2005 l'avènement du lightweight Java dans End of the Java Web Frameworks Survey road for invasive middleware?. Espérons que son message continuera à influencer Big Blue et qu'ObjectGrid ne disparaîtra pas dans l'imposante stack Websphere.

[1] cf. l'EntityManager à la JPA qui n'a pas d'égal pour manipuler les POJOs des la grille

Java Web Frameworks Survey

Peter Karich présente dans Java Web Frameworks Survey un comparatif des huit frameworks Web qui suivent :

• Click Framework
• Echo2
• GWT
• JSP
• Thinwire
• Wicket
• WingS
• ZK Framework

L'application était un simple bouton avec une zone de texte, dans laquelle on devait mettre un morceau de code permettant de dessiner un graphique. Pour le graphique, la librairie gnuplot a été utilisée.

Le comparatif nous permet de découvrir certains frameworks peu connus. Selon l'auteur, le framework Click présente des similarités avec Wicket et propose des aspects plus simples. Mettre en place sa première page avec Echo n'est pas très compliqué. En revanche GWT demande un certain coût d'entrée... (Nous avions partagé certaines de ces conclusions dans notre Web Framework Contest en Octobre dernier.

La conclusion de cette étude est que comme souvent chacun de ces frameworks a ses forces et ses faiblesses, et que si vous devez en choisir un il faut se poser les bonnes questions: un support est-t-il disponible ? Il y a t'il une communauté active? Quelles sont les possibilités d'intégration à une application existante ?

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

Kirk Pepperdine au Paris JUG

Kirk Pepperdine est venu présenter au Paris JUG les enjeux de performances en Java. En attendant que la présentation de Kirk soit disponible, les points essentiels :

• L'émergence des processeurs multi-coeurs révèle des problèmes de concurrence d'accès qui n'apparaissaient pas auparavant : une application peut s'exécuter moins vite sur un processeur multi-coeur à cause d'apparition de goulets d'étranglement (synchronisation, etc).
• Les APIs java.util.concurrent introduites avec Java 5 (en même temps que la clarification du modèle mémoire) simplifient le développement d'applications hautes performances.
• Les bases de données ne sont pas encore optimisées pour les architectures multi-coeurs et sont concurrencées frontalement par les grilles de données (Terracotta, Coherence, etc) qui elles exploitent les opportunités de parallélisme.
• Diagnostiquer un problème des performances d'une application Java nécessite d'étudier simultanément les quatre couches de "The Box" [1] : Hardware, JVM, Application et People.
• Les premiers outils pour ce type de problèmes sont le Gestionnaire des Tâches sous Windows et vmstat/top sous Unix/Linux car ils donnent une vision d'ensemble (IO, CPU Système, CPU Applicative, etc).

D'autres blogs parlent de la venue de Kirk Pepperdine : Le touilleur Express : Présentation de Kirk Pepperdine au Paris Java User Group, David Gageot: Troisième rencontre du Paris Java User Group.

Merci encore aux organisateurs du Paris JUG et rendez-vous le 13 mai pour des présentations sur la Productivité des développements Java (Guillaume Duquesnay) et Maven (Arnaud Heritier).

[1] cf InfoQ : The Box: A Shortcut to finding Performance Bottlenecks par Kirk Pepperdine