La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Cloud: Jboss AS7 se déploie sur OpenShift, OpenStack se dévoile dans un guide
• RabbitMQ + Cloud Foundry: Cloud Messaging that just works

Le coin de la technique

• Apache Commons Lang 3

Actualité éditeurs / SSII

Cloud: Jboss AS7 se déploie sur OpenShift, OpenStack se dévoile dans un guide

Le Cloud, on en entend beaucoup parler mais peu le voient vraiment arriver dans leur travail de tous les jours. Pourtant, les choses avancent vite.

OpenShift : du coté de Redhat/JBoss tout d’abord, qui a annoncé cette semaine la disponibilité de JBoss AS 7 sur leur Cloud. Tournant sur OpenShift (le Paas à la RedHat) lui même tournant sur CloudForm (Iaas), l’offre est ainsi la 1ere offre compatible JEE6 out of the box. Il est intéressant de noter qu’elle permet apparemment le déploiement d’un nombre illimité d’applications sur AS 7, et ce gratuitement, en utilisant l’offre OpenShift Express. A nous la puissance du standard web profile (voire plus) ! Et pour simplifier l’approche, l’annonce pointe d’ailleurs vers des vidéos montrant la facilité du processus de déploiement d’applications JEE6: on a presque l’impression qu’un simple git push suffit ! Une autre vidéo montre comment déployer la « Spring Pet Clinic ».

OpenStack: Mais comme toute nouvelle techno émergente, il n’y a pas un seul standard. Ubuntu, Intel, Dell et de nombreuses autres entreprises, de leur coté, développent l’OpenStack qui se définit comme un Operating System pour le Cloud, lorgnant donc du coté de l’Iaas. Si le projet existe depuis quelques temps déjà (il avait été lancé par Rackspace et la NASA il y a un an), la sortie du guide « Openstack Beginner Guide for Ubuntu Natty » est l’occasion d’en parler. Annoncé ici et disponible en PDF, le guide vous permettra d’avoir une première approche de la stack en vous lançant dans les configurations réseau, déploiements d’images et autres barbarismes en ligne de commande. Comment ça, ça n’est pas du Java et ne vous concerne pas ? Vos projets futurs risquent pourtant fort de tourner sur ces infrastructures. Attention, la lecture de « OpenStack Overview » (pdf disponible ici) est conseillée pour avoir une petite idée avant de se lancer dans la lecture du guide complet. Vous vous y familiariserez avec et découvrirez les 3 composants de l’ensemble:

• OpenStack compute qui permet de provisionner des ressources en mettant à disposition un réseau de machines virtuelles
• OpenStack Object Store qui permet le stockage de données de façon redondante et scalable
• OpenStack Glance qui est un catalogue d’images serveur

Mais l’interopérabilité étant maintenant une donnée que les entreprises prennent en compte (à raison !), il y a fort à parier que toutes ces technologies se coupent et se recoupent allègrement. RedHat a d’ailleurs évoqué une version future de OpenShift tournant sur OpenStack.

RabbitMQ + Cloud Foundry: Cloud Messaging that just works

Restons dans les nuages en faisant un petit tour du côté de Cloud Foundry, la solution de Platform as a Service de VMware (nous en parlions ici). Après l’intégration de MySQL, MongoDB et Redis, voici donc l’arrivée de RabbitMQ parmi les nouveaux services proposés par la plateforme qui fait sien le slogan de RabbitMQ: Cloud Messaging that just works. Rappelons que RabbitMQ a été racheté par SpringSource/VMware il y a un an et demi et cette nouvelle annonce valide finalement leur stratégie pour offrir une écosystème complet. En effet, comme rappelé dans l’annonce de Cloud Foundry, le messaging est une brique essentielle pour entre autre:

• la maintenabilité: minimisation de l’impact pour de nouvelles alertes, nouveaux rapports ou logs
• la scalabilité: on peut déléguer par exemple des tâches à des workers particuliers
• l’efficacité: les informations peuvent être poussées vers les différents composants, évitant de faire du polling ou de se synchroniser sur une base
• la robustesse: les queues de messages permettent de temporiser si des instances ou des composants sont désactivés

De plus RabbitMQ implémente le protocole AMQP (versions 0-8 et 0-9-1) qui, contrairement à JMS, a l’avantage de ne pas être enfermé au seul monde Java. C’est d’autant plus intéressant que cette plateforme supporte pour l’instant 3 langages: Java (avec aussi Scala et Groovy), Ruby/Rails et JavaScript (node.js). L’interopérabilité sur ces différents frameworks peut donc être facilitée par RabbitMQ.

Reste que Cloud Foundry est encore dans une phase bêta, la partie monitoring par exemple reste encore très perfectible comparée à son concurrent direct Google App Engine. Nous n’avons pas pu non plus tester les performances d’applications tournant sur cette plateforme.

Vous pouvez commencer dès maintenant grâce à ces tutoriels : Spring 1, Spring 2, exemple d’application sur github et Spring AMQP.

A noter: AMQP est d’ailleurs le protocole de messaging utilisé sur OpenStack, mentionné dans l’entrée précédente, grâce à RabbitMQ et en Python (ce dernier n’est pas un langage supporté par Cloud Foundry),

Le coin de la technique

Apache Commons Lang 3

Les librairies d’Apache, Apache Commons se retrouvent dans de nombreux projets et permettent de s’appuyer sur du code qui marche et qui fait bien ce qu’on lui demande. Mais il est vrai que ces librairies ont perdu de leur superbe, n’étant pour la plupart pas « Java 5 compliant ». Qui a encore envie de caster ses objets alors que Google Guava, lui, utilise les generics ? Pour pallier en partie à ce problème, ce sont les commons-lang qui ont récemment débarqué en V3, apportant dans de nombreuses méthodes le support de ces generics.
C’est sur Web Tambouille que l’on trouve l’article le plus complet leur étant consacré. Il y détaille le contenu de divers packages:

• lang3.* : contient des utilitaires pour les String, Array, Object…
• lang3.concurrent.* : quelques ajouts enrichissant java.util.concurrent.
• lang3.builder.* : divers Builder, comme le EqualsBuilder() qui permet de comparer facilement des objets
• lang3.reflect.* : des utilitaires pour améliorer votre code traitant de réflexion
• lang3.mutable.* et lang3.tuple.* : vous avez toujours rêvé de pouvoir changer la valeur de vos entiers ou de pouvoir en retourner plusieurs en un seul appel de méthode ? Vous trouverez ici votre bonheur

Attention tout de même: la compatibilité ascendante n’est pas assurée: il faudra au minimum recompiler car les anciens packages n’ont pas étés conservés.
Bref, cet article est à lire car on a souvent tendance à passer à coté de toutes les fonctionnalités offertes alors que cette librairie est (souvent) déjà dans nos projets. C’est dommage, non ?

La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Jenkins : The Definitive Guide
• Java, Kotlin, Ceylon… Que d’îles !

Le coin de la technique

• Springsource: des nouveautés en pagaille
• Java en entretien technique
• Fork/Join: le multithread facile en Java 7
• Sortie de Groovy 1.8.1 et 1.9 beta 1
• Sortie de Google App Engine SDK 1.5.2
• Scala : vers une version « classique » 2.9.1 et une version .Net
• ClojureScript

Actualité éditeurs / SSII

Jenkins : The Definitive Guide

Wakaleo Consulting sort un ebook gratuitement téléchargeable : Jenkins The Definitive Guide. Comme son nom l’indique c’est un guide très complet sur le serveur d’intégration continue, ex-Hudson. Le guide couvre :

• installation et configuration
• sécurisation
• notifications email, IRC, Jabber, SMS et autres
• structuration des jobs
• promotions de bonnes pratiques de développement, via Checkstyle, PMD, FindBugs et autres plugins

Il est bien écrit (en anglais) et mérite d’y jeter un œil, que ce soit pour apprendre, approfondir ou réviser.

Java, Kotlin, Ceylon… Que d’îles !

Ces derniers temps furent très mouvementés dans le monde des langages alternatifs de la JVM.

On sait maintenant que Kotlin n’est plus seulement connu pour être une île perdue en Russie. C’est aussi un nouveau langage proposé par l’équipe de JetBrains censé tourner sur JVM (et encore un de plus, diront certains). Dans les particularités remarquables du langage, nous trouvons :

• les closures et les fonctions d’ordre supérieur,

fun  filter(Iterable items, predicate : fun(T) : boolean) : Iterable { … }
filteredPersons = filter(persons, { it.getAge() >= 18 });

• les fonctions d’extension qui permettent d’ajouter de nouvelles méthodes à des classes,
• le pattern matching,

when (x) {
  is Int => print(x)
  is List => print(x.sum())
  !is Number => print("Not even a number")
  else => print("can't do anything")
}

• La notion de tuple,
• La couche objet habituelle avec des classes finale par défaut,
• La réification des generics permettant de conserver les informations sur le type des arguments d’un type générique au runtime.

Ce langage, vous ne pouvez pas encore l’utiliser car il n’est actuellement disponible qu’à l’état de spécification. Un peu comme Ceylon, en fait, qui est aussi une île. Et d’ailleurs, comme Ceylon, il se veut être une simplification de Scala. Bien sûr, ce nouveau langage à créé le buzz auprès de la communauté des développeurs Java et Scala.

D’ailleurs Gavin King en a profité pour nous donner un rapport d’avancement sur Ceylon. Et bien… Il avance dans le travail de son compilateur. Mais il semble qu’après l’annonce de Kotlin, Gavin s’est malheureusement attiré à lui le buzz et la guerre pseudo-fratricide qui l’accompagne. La situation lui ayant échappé, Gavin a décidé de fermer les commentaires de son post.

Tous ces nouveaux langages ont donné envie à Stephen Colebourne d’écrire un essai (au sens littéraire du terme) sur deux notations utilisées dans la déclaration de type : la déclaration de type classique (comme en Java ou C) et la déclaration de type inversée (comme en Scala ou en Pascal). Stephen réalise sa démonstration au travers de différents langages : Java, Java avec les lambdas expressions en utilisant la proposition strawman, Java avec les lambdas expressions en utilisant la proposition BGGA, Ceylon, Fantom, Gosu, Kotlin et Scala. Nous vous laissons lire l’article et en tirer vos propre conclusions.

Le coin de la technique

Springsource: des nouveautés en pagaille

SpringSource nous fait le plein de nouveautés avec plusieurs sorties:

Spring Data JPA 1.0

Le projet Spring Data vise à faciliter les accès aux bases de données et à gagner encore et toujours en productivité. Au travers de cette API, il est possible d’utiliser aussi bien des bases NoSQL que des bases relationnelles.

L’API est pour l’instant relativement succincte. Il est possible de faire du CRUD et de l’interrogation sans écrire une seule requête grâce à un système de convention de nommage des méthodes.

L’interface de base se nomme Repository. Si votre interface UserRepository étend Repository et définit une méthode findByName(String name), vous pouvez directement l’utiliser pour rechercher vos éléments. Le framework, en fonction de l’environnement que vous avez, construira une requête sur l’entité User en cherchant celle qui a le nom donné en paramètre. Vous définissez le contrat, le framework s’occupe de l’implémentation.

Avec Spring Data JPA 1.0 qui arrive en release finale, il est possible d’utiliser JPA 2.0 au travers de l’abstraction fournie par Spring Data. En plus du CRUD, l’API Criteria de JPA a été portée avec son lot de prédicats. Il est aussi possible d’utiliser des Queries en JPQL et de les associer aux méthodes du Repository pour des implémentations personnalisées de certaines méthodes. Cette première version reste verbeuse, mais Spring assure vouloir réduire le code technique avec la maturité à venir de son nouveau produit.

Spring Data 1.1.0.M2

Spring Data Graph 1.1.0.M2 en version minestrone ajoute de nouvelles fonctionnalités sur la gestion de la base de données orientée graphe Neo4J. En plus de la correction de quelques bugs, l’API supporte maintenant la version 1.4. Tant que nous y sommes, si vous choisissez d’étudier les bases de données graphe, essayez Gephi pour la visualisation et l’exploration des données: c’est visuellement intéressant !

Spring Gemfire 1.1.0.M1

Spring Gemfire est arrivé en version 1.1.0.M1 la semaine dernière.

Les applications propulsées par Spring peuvent déjà se préparer à utiliser la version 6.6 du système de gestion de données réparti de VMWare. Il permet aussi d’utiliser l’abstraction de cache apportée par Spring 3.1. La connexion aux Cache Server de GemFire est rendue disponible (pour la réplication de session HTTP par exemple). Enfin, pour la création de requête, dites au revoir à la génération par chaînes de caractères (avec inclusion des paramètres), et bonjour au templating avec l’utilisation des paramètres variables.

Java en entretien technique

Ah les questions techniques lors d’un recrutement… Quel développeur n’a jamais eu peur de faire face à ces questions alors même qu’il estime bien connaître les méandres de la spec Java. Mais les points flous et d’incompréhension peuvent être nombreux !
Dans un récent post, Peter Lawrey revient sur certains de ces points et nous livre son analyse. Nous ne reparlerons pas (zut, trop tard !) de l’éternel « pass by value VS pass by reference » qui génère toujours beaucoup de commentaires, mais nous pourrons citer par exemple:

• Les modificateurs transient et volatile
• Overriding, overloading: lequel fait quoi ?
• que retourne boolean.class.getSuperclass() ?
• Rappelez moi la définition d’un Java Bean ?

Ainsi que quelques autres questions. Rien de bien nouveau mais une petite piqûre de rappel fait toujours du bien, même aux plus calés.

Tant que nous sommes sur les questions lors d’une entretien, n’oubliez pas que si vous avez à réaliser un bout de code mais pas vraiment l’envie de le faire, il est toujours possible de s’en sortir en utilisant la technique suivante. Dans celle-ci, l’auteur pousse l’exagération jusqu’à la mauvaise fois en demandant des spécification extrêmes sur ce qui lui est demandé de réaliser, une simple copie de fichiers. Notez qu’il est formellement déconseillé d’utiliser cette technique lors d’un entretien chez Xebia

Fork/Join: le multithread facile en Java 7

Alors que le nombre de core par CPU ne cesse de croître, il serait peut être temps que nous utilisions à bon escient les ressources disponibles sur nos serveurs, non ? Java sait depuis toujours faire du multi-threading (encore heureux !) mais il est généralement très compliqué de faire du code multi-threadé efficace et maintenable. Notamment, la synchronisation entre les différent Thread a toujours été source de problèmes. Java 5 puis 6 apportèrent d’importantes innovations, sous la forme du package java.util.concurrent qui fournit:

• les Executors, qui abstraient des pools de threads, ainsi que les Future et Callable
• des queues et Collections thread-safe
• le support de la déclaration de timeout sur les opérations
• des classes implémentant des patterns de synchronisation et d’exclusion mutuelle, comme les Barrier ou Countdown Latch (plus de détails chez O’Reilly)
• le package java.util.concurrent.atomic fournissant des wrappers pour des variables simples permettant des opérations de modification atomiques sur ces variables

Ces apports au langage étaient les bienvenus. Néanmoins, certains type de tâche, et notamment les algorithmes de type « diviser pour régner » ou « map/reduce », requièrent des fonctionnalités qui n’étaient pas offertes .

Julien Ponge nous gratifie d’un article sur Oracle Tech. Network avec l’exemple d’utilisation suivant: on désire compter le nombre d’occurrences d’un mot donné dans des fichiers répartis dans une arborescence du filesystem. Et ca tombe bien, Java 7 fournit justement une implémentation du principe fork/join au travers de la classe abstraite ForkJoinTask et de ses sous-classes. Le filesystem est parcouru grâce à des tâches récursives, mais parallèles. Initialement on a une tâche de type FolderSearchTask qui étend RecursiveTask et crée:

• pour chaque répertoire, une nouvelle tâche FolderSearchTask
• pour chaque document, une DocumentSearchTask qui étend aussi RecursiveTask et compte le nombre d’occurrences du mot recherché

Au final l’algorithme est rendu quasi-trivial avec l’utilisation du nouveau Framework, alors qu’il n’en aurait pas été de même avant Java 7. En effet celui-ci permet de résoudre des problèmes récursifs dont ne ne connaît à priori pas la taille. Dans le cas exposé le comptage débute alors qu’on ne sait pas quelle sera la profondeur du système de fichiers ni le nombre de documents qui sera rencontré.

Une image valant mieux qu’un long discours, voici une illustration assez explicite accompagnant l’article dont nous vous conseillons fortement la lecture:

Sortie de Groovy 1.8.1 et 1.9 beta 1

Le projet Groovy continue à avancer et sort la première version corrective de la branche 1.8 et sa nouvelle beta de la 1.9.

Au menu pour la 1.8.1 :

• plus de 40 bugfixes.
• amélioration du JSonBuilder avec un mode streaming.
• la suite du chantier sur les performances des opérations arithmétiques sur type primitifs.

Pour la 1.9 beta 1 :

• plus de 20 bugfixes
• intégration des nouveautés Java 7 liées au Project Coin

Pour le détail complet, voir l’annonce sur DZone ou les release notes JIRA des versions 1.8.1 et 1.9 beta 1.

Sortie de Google App Engine SDK 1.5.2

Une nouvelle version 1.5.2 du SDK de Google App Engine vient de sortir. Pour rappel, GAE est une plateforme as a service (PaaS) permettant d’héberger dans le cloud des applications web Java et Python ( et prochainement Go, le nouveau langage développé par Google).

En plus de quelques bogues corrigés, cette release apporte quelques nouveautés intéressantes, comme :

• Des paramètres pour ajuster le ratio coût/performance de l’application: Possibilité de définir le nombre minimale d’instances au repos, et la latence minimale d’attente, qui permet d’ajuster le temps minimum qu’une requête doit attendre dans la queue avant d’être traitée par une instance.
• Suppression de la contrainte de créer des index explosés pour « les big entities » et réduction des index personnalisés.
• Les statistiques du Datastore peuvent être regroupées par espace de nom.
• Des informations supplémentaires ont été ajoutés à la page d’administration des Task Queue.
• La limitation de la taille de la Pull Task est passée à 1MB.

Pour plus d’infos, voir la release note.

Force est de constater que la plateforme de Google s’enrichit de release en release. De nombreuses limitations se réduisent voire disparaissent au fur et à mesure. Les possibilités de monitoring, de tuning, et d’administration des backends commencent à bien s’étoffer.

Scala : vers une version « classique » 2.9.1 et une version .Net

Scala va bientôt une version 2.9.1 qui est maintenant disponible en première Release Candidate. Cette version devrait corriger un certain nombre de bug et mettre en place des améliorations en particulier au niveau de l’interpréteur.

Par ailleurs, Miguel Garcia, de l’équipe Scala à l’EPFL, vient d’annoncer une avancée majeure dans l’adaptation du langage de Martin Odersky à la plateforme .NET. Dans ce projet financé par Microsoft, l’adaptation a été rendue possible grâce au projet IKVM.NET. IKVM est un projet mature et toujours en activité qui implémente un framework Java dédié aux plateformes Mono et .NET. On y trouve :

• la JVM compilée pour .NET,
• une implémentation .NET de bibliothèques Java,
• et un convertisseur JAR vers DLL.

Miguel a mis en place un plugin apppelé jdk2ikvm pour le compilateur Scala qui permet de convertir un programme Scala pour JDK en programme Scala pour IKVM et donc .NET. Les développements ne sont actuellement pas complètement stabilisés, mais ils sont utilisables aux dires de l’auteur. Parmi les développements futurs, Miguel prévoit de développer un plugin Scala pour l’IDE Visual Studio et l’adaptation des collections concurrentes aux modèle de gestion de thread de .NET.

ClojureScript

Du côté de Clojure, l’annonce a été faite par Rich Hickey en personne (le créateur de Clojure) lors du Clojure NYC Meetup de juillet. Rich nous a appris la sortie de ClojureScript (voir la vidéo). ClojureScript est une adaptation de Clojure non pas à la plateforme .NET, mais à la plateforme JavaScript. Vous écrivez vos programmes en Clojure et ça vous le compile en JavaScript. La motivation derrière ce projet vient du fait que JavaScript est un langage donnant un accès un scope d’applications de plus en plus large, allant du client au service. Cependant, les développeurs de ClojureScript considèrent que la langage JavaScript possède un certain nombre de faiblesses, notamment pour la construction d’applications robustes qui nécessite de la discipline et le respect de conventions. C’est sur ce point que ClojureScript compte apporter des solutions. Il est possible récupérer une version depuis GitHub.

• En décembre 2008, SpringSource annonce la sortie de tcServer.
• En mai 2009, SpringSource annonce la mise à disposition gratuite de sa suite de développement Spring Tool Suite.
• En mai 2009, SpringSource rachète Hyperic l’éditeur de l’outil de supervision HypericHQ, permettant ainsi de disposer d’une solution de monitoring performante.
• En août 2009 déjà, le mois du rachat de SpringSource par VMware, Rod Johnson annonçait sur son blog son intension de lancer Cloud Foundry tout en donnant sa vision sur une gestion unifiée du cycle de vie des applications au travers des solutions de SpringSource. L’offre classique de Cloud Foundry est d’ailleurs toujours en ligne, mais à une nouvelle adresse.
• En avril 2010, SpringSource/VMware rachète RabbitMQ, proposant ainsi une brique de messaging prête pour le Cloud et intégrée avec Spring.
• En mai 2010, SpringSource/VmWare se dote d’un cache distribué en rachetant GemStone qui édite le produit GemFire.
• En septembre 2010, SpringSource/VMware annonce la sortie de sa plateforme vFabric.
• Au SpringOne2GX en novembre 2010, SpringSource/VMware annonce sa plateforme Code2Cloud, qui propose ni plus ni moins d’apporter le Cloud au développeur via la mise à disposition d’une suite logicielle de gestion du cycle de vie des applications. Cette plateforme Cloud met à disposition des développeurs des outils tels qu’un bugtracker basé sur Bugzilla, une intégration avec Mylyn pour Eclipse, un Gestionnaire de code source avec Git, une plateforme d’intégration continue avec Hudson, ainsi qu’un ensemble d’outils intégrés via STS.

La liste n’est sûrement pas exhaustive, mais tout cela ne serait pas complet si SpringSource ne proposait pas une mise à jour de son framework Spring en version 3.1. Cette version propose notamment un support de fonctionnalités de cache, un support du protocole AMQP ou bien encore un support des profils permettant de gérer plus facilement des configuration de beans différentes en fonctions des environnements.

Qu’est-ce que Cloud Foundry?

Cloud Foundry, c’est tout d’abord un projet de Platform as a Service Open-Source sous licence Apache 2.0 hébergé sur GitHub avec un site officiel. Mais c’est également une plateforme d’hébergement en mode PaaS, permettant de déployer ses applications en un clic depuis la suite applicative Spring Tool Suite. Cloud Foundry se veut être le premier fournisseur « Plateform as a Service » réellement basé sur une solution ouverte, qui n’implique pas un lock-in technologique.

SpringSource/VMware à vu les choses en grand puisque le projet se veut multi-langages en proposant le support d’au moins 3 langages différents: Java (+ différents langages tournant sur la JVM), Ruby, et JavaScript, ainsi que le support de différents frameworks/DSL Web de premier rang, tels que Rails ou bien encore Sinatra pour Ruby, ainsi que Grails pour Groovy.

Au chapitre stockage de données, l’offre de Cloud Foundry n’est pas en reste puisque sont proposés les supports d’une base clé/valeurs via le support Redis, d’une base orientée document via le support de MongoDB, et d’une base de données relationnelle via le support de MySQL.

La suite Spring Tool Suite, qui permet de développer des applications SpringSource sous Eclipse, permet d’ores et déjà d’accéder à l’ensemble de l’outillage nécessaire pour développer une application prête pour Cloud Foundry.

Bon à savoir: Une version Cloud Foundry Micro Cloud sera bientôt proposée au téléchargement, elle permettra de faire tourner dans VMware Fusion ou VMware Player une image iso correspondant à une mono instance Cloud Foundry adaptée à un Desktop.

Face à la richesse de la solution proposée, certains concurrents semblent faire pâle figure, et risquent d’être relégués à un rôle de challenger de second rang ou bien d’offre Cloud d’entrée de gamme.

Google et son App Engine a du souci à se faire, et va devoir être innovant s’il veut conserver une place de choix. La solution de CloudBees quant à elle est en train de se faire couper l’herbe sous le pied, puisque SpringSource/VMware propose maintenant non seulement une offre PaaS de Run at Cloud avec Cloud Foundry, mais également une offre en preview de Build at Cloud avec Code2Cloud.

Tout cela profite bien évidemment au monde du développement qui voit s’ouvrir devant lui de nouvelles perspectives qui commençaient à se faire attendre.

NB: Il est tout de même nécessaire de noter que l’accès à la Beta de la plateforme est conditionné par l’obtention d’un compte, ce qui peut mettre un certain temps. Il semblerait que les équipes aient du mal à suivre la demande. Autre point en suspens, il n’est pour l’instant annoncé aucun prix relatif à l’offre de SpringSource/VMware, espérons que les prix ne fassent pas l’effet d’un pétard mouillé. Pour le moment, l’accès à l’offre est gratuit, et ce au moins jusqu’à la fin de la Beta.

Liens intéressants

Vous trouverez quelques liens ci-dessous permettant de creuser le sujet:

• Le site communautaire du projet est disponible à l’adresse suivante: http://www.cloudfoundry.org.
• La plateforme d’hébergement de Cloud Foundry : http://www.cloudfundry.com.
• Le projet GitHub: https://github.com/cloudfoundry.

Ainsi que différents articles permettant de bootstrapper rapidement un projet Cloud Foundry avec sa technologie préférée:

• Déployer son application Grails en une étape avec Cloud Foundry.
• Roo + Cloud Foundry = La productivité dans le Cloud.
• Cloud Foundry pour les développeurs Spring – Très bon article sur l’utilisation des outils STS pour travailler avec Cloud Foundry
• Lancement de Cloud Foundry – La première plateforme PaaS ouverte de l’industrie informatique

Actualité éditeurs / SSII

• Configuration Spring 3.1 : des parfums de Cloud Computing et de Continous Delivery
• Partenariat entre StormMQ et Kaazing

Le coin de la technique

• Node.JS stable en 0.4.0

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

• Peut-on faire du RIA sans Flash ?

Actualité éditeurs / SSII

Configuration Spring 3.1 : des parfums de Cloud Computing et de Continous Delivery

Chris Beams a présenté à SpringOne 2GX les nouveautés de configuration de Spring Framework 3.1. Les tendances clefs sont :

• L’approche Continuous Delivery grâce à la gestion des configurations de chaque environnement avec des profiles,
• Le support des architectures Platform as a Service grâce à une API d’Environnement qui permettra d’injecter aux applications les configurations d’environnement et de topologie,
• L’approche Infrastructure as code (cf ThoughtWorks January 2011 Technology Radar) avec la possibilité de gérer complètement la configuration par programmation.

La gestion des configurations par environnement est réalisée par la taggage de beans par des profiles. Si un profile n’est pas activé, les beans qui lui sont associés ne sont pas chargés.
On peut appliquer ces profiles sur les fichiers XML (<beans profile="development">), les beans @Composant, les classes @Configuration comme sur les annotations applicatives qui héritent des annotations Spring. Le premier cas d’utilisation est le chargement d’une base de données embarqués HSQLDB pour les tests unitaires alors qu’une DataSource JNDI est utilisée sur les serveurs.

Cette approche est à la fois inspirée par les configurations programmatiques Grails et par l’astuce d’import d’un fragment spécifique à l’environnement ( <import resource="classpath:applicationContext-${env}.xml" />).

L’API Environment expose de façon unifiée les paramètres spécifiques à chaque environnement (variables système, JNDI, init-param d’application web, configuration middleware, etc).
Cette API permettra à des solutions de Java Platform as a Service d’injecter les éléments de configuration aux applications Spring. La solution AppCloud de VMWare sera surement la première à tirer partie de cette API .

Plus de détails sur les profiles dans SpringSource Blog – Spring 3.1 M1: Introducing @Profile.

Partenariat entre StormMQ et Kaazing

La semaine dernière StormMQ et Kaazing annonçaient un nouveau partenariat.

StormMQ est une entreprise anglaise qui propose un service hébergé de type MOM (Message-Oriented Middleware) ou un cluster clé en main à héberger dans l’entreprise. Derrière se cache un broker de message respectant le protocole AMQP. Plusieurs modes d’accès sont possibles, par l’intermédiaire d’une API java à l’aide d’une librairie RabbitMQ ou d’une API REST en PHP par exemple.

Kaazing est un des tous premiers serveur offrant un service pour les WebSockets. Les WebSockets permettent d’établir des communications full-duplex à travers le réseau web, évitant les anciennes techniques de long polling pour maintenir une communication avec le serveur et écouter des événements.

Avec ce partenariat, StormMQ compte proposer une solution clé en main permettant de faire de la messagerie sur le web. Il est encore un peu tôt pour dégager de vrais cas d’utilisation en entreprise mais la synergie entre ces deux solutions se trouve entre d’un côté un client 100% javascript facile à déployer ou à adapter et d’un autre côté un serveur de messagerie déporté évitant la maintenance et garantissant une certaine scalabilité.

Le coin de la technique

Node.JS stable en 0.4.0

Après une succession de versions 0.3.x étiquetées « instables », LinuxFr nous apprend que Node.JS arrive aujourd’hui en version 0.4.0 stable. Rappelons que NodeJs est un serveur full-javascript dont on entend de plus en plus parler. D’ailleurs, c’est tout le langage javascript qui semble monter en puissance ces temps-ci. Nous ne nous appesantirons pas trop sur les nouveautés de Node.JS, mais il est bon d’apporter quelques précisions quand à Javascript. Nous sommes nombreux à avoir toujours vu dans ce langage un langage de seconde zone, assez inintéressant à part pour effectuer quelques requêtes ajax et dynamiser une page html. Mettons nous bien dans la tête que ce temps est révolu. Des bindings existaient déjà pour les librairies graphiques client lourd comme GTK ou QT mais aussi Mozilla XUL. Dans Open/LibreOffice, on pouvait utiliser Javascript pour définir ses macros et Mozilla Rhino était inclu dans Java 6. Maintenant, Javascript débarque coté serveur. La guerre que se sont menés à coup de benchmarks les différents éditeurs de navigateur nous permet aujourd’hui d’avoir des performances intéressantes pour Node.JS qui s’appuie sur V8, le moteur javascript de Chrome.
Alors non, ce n’est pas demain la veille que nous remplacerons nos Tomcat et autres GlassFish par Node.JS. Néanmoins la tendance est à suivre de près.
Pas plus tard que la semaine dernière, nous notions par ailleurs que JQuery est maintenant buildé sous ce serveur, et ce ne sont pas les seuls à l’utiliser: Yammer et d’autres utilisent eux aussi Node.JS. Pour faire écho à la conclusion de la news « Peut-on faire du RIA sans Flash ? », Javascript est le langage à suivre en 2011 !

Dernière minute: Web Tambouille publie aujourd’hui le 1er d’une série de 4 articles dédiés à Node.JS. A découvrir d’urgence !

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

Peut-on faire du RIA sans Flash ?

Zenexity a organisé un événement ce 9 février intitulé « Peux-on faire du RIA sans Flash ? ».
L’événement était constitué de 4 interventions de 20 minutes chacune présentées par des employés de zenexity. Les 4 interventions ont brossé un tableau des RIA 100% html, en mettant l’accent sur les innovations qu’apportent HTML5 aujourd’hui. En partant du design web, en passant par la fascinante API canvas, les CSS transitions avec des démos particulièrement convaincantes pour finir par une intervention de Guillaume Bort mettant l’accent sur les avantages au niveau architecture web de l’approche html5 au niveau sémantique et notamment sur l’aspect propriétaire du flash.
Les slides sont en html5 bien sûr, disponible sur le site zengularity.
Alors certes le parc de navigateurs limite l’adoption de ces innovations, mais pour un projet démarrant aujourd’hui le choix n’est pas si évident entre du flash et du html5. Ce qui marque c’est surtout la relative facilité d’usage de ces éléments à condition d’accepter javascript comme un langage de premier plan. Le langage à (re)-apprendre en 2011 ?

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• SpringOne2GX 2010 – Les annonces de SpringSource
• Spring ROO 1.1.0
• Sortie de GWT 2.1
• Mozilla Rainbow: enregistrement audio et video dans le browser

Le coin de la technique

• jOOQ 1.4.2, ou comment faire du SQL object

Actualité éditeurs / SSII

SpringOne2GX 2010 – Les annonces de SpringSource

La semaine dernière se tenait la conférence SpringOne 2GX à Chicago. Cette conférence a été le théâtre de nombreuses annonces du duo SpringSource/Vmware. Cette actualité est notamment relayée sur le blog de Rod Johnson.

Code2Cloud

SpringSource présente ici une forge logicielle mettant en oeuvre des services tels que :

• un système de bug tracking basé sur Bugzilla,
• utilisation du système de bug tracking avec Mylyn
• la gestion du code source avec Git, le système de contrôle de version distribué phare du moment,
• de l’intégration continue avec Hudson,
• une intégration de cette nouvelle plateforme avec STS.

Code2Cloud a pour ambition de simplifier la vie des développeurs tout en augmentant leur productivité en leur permettant de se focaliser sur les aspects métiers. Nous ne manquerons pas de suivre l’actualité de ce projet et de l’évaluer dès que la Developer Preview sera disponible. Cette preview ne devrait pas être disponible avant le début 2011 (cf FAQ).
Pour ceux qui se posaient la question, le code de ce projet sera fournit sous les termes de la GPL.

Preview de Spring 3.1

De nombreuses évolutions nous attendent dans la version 3.1 du framework Spring avec au menu :

• le support des servlet 3.0,
• les profils d’environnement permettant de charger des propriétés différentes selon que l’on soit sur un environnement de développement, de recette ou de production (ce principe est notamment utilisé dans Grails par exemple),
• une couche d’abstraction pour l’accès aux systèmes de cache (EhCache et GemFire dans un premier temps) et une nouvelle annotation @Cacheable,
• un effort a aussi été réalisé afin de diminuer le nombre de configuration qu’il est possible de réaliser en xml mais pas en utilisant des annotations.

Cette version semble prévue pour le début de l’année 2011 (la roadmap s’arrête actuellement mi-janvier 2011 avec la 3.1M2).

Mais SpringSource annonce de nouveaux projets venant s’ajouter au portefeuille. Les voici:

Spring Data

SpringSource s’attaque avec Spring Data aux bases de données NoSql. L’idée est de fournir un moyen simple d’accès aux bases de données non relationnelles ainsi qu’à des technologies telles que Oracle RAC.
Le projet Spring Data contient de nombreux sous projets permettant notamment l’accès aux bases de données orientées :

• clé-valeur avec le support actuel de Redis, le support de Membase est prévu prochainement,
• document avec le support actuel de CouchDB et de MongoDB,
• colones avec le futur support de HBase, de Hadoop et de Cassandra,
• graphe avec le support de Neo4j.

Le projet propose un système de templating bien connu des développeurs utilisant le framework Spring, pour permettre l’accès à ces bases de données.

Spring Mobile

Ce projet a pour but de fournir un meilleur support pour l’écriture d’applications destinées aux terminaux mobiles. Il repose sur des évolutions de Spring MVC et un partenariat avec Google autour de GWT.

Spring Social

Ce projet doit simplifier les interactions avec des services des réseaux sociaux tels que Twitter, Facebook ou encore LinkedIn. Spring Social fournira :

• un Social Network Template permettant d’interagir avec les réseaux sociaux supportés (LinkedInTemplate, FacebookTemplate …),
• une intégration OAuth pour la gestion des autorisations (une request factory signera les requêtes REST avec les informations d’autorisation OAuth requises)
• le mécanisme nécessaire à l’extraction du Facebook User ID.

SpringSource fournit un exemple d’application permettant de voir comment fonctionne ce nouveau projet.

Spring Payment Services

Ce projet facilitera l’intégration de services de paiement dans les applications Spring. Ce projet réalisé en partenariat avec Visa qui fournit l’expertise métier aux développeurs de SpringSource vise à permettre différents types de paiements (paiement en ligne, paiement mobile, paiement de personne à personne …) via différents fournisseurs de services de paiement (donc pas uniquement Visa). Spring Payment Services étant encore en incubation, il est possible que les API subissent un lifting plus ou moins prononcé. Il est donc préférable de l’utiliser uniquement pour évaluation à l’heure actuelle.

Spring ROO 1.1.0

En restant toujours dans l’écosystème de SpringSource, Spring Roo 1.1.0 vient de sortir après 10 mois de gestation.

Spring Roo est un outil de haute productivité de SpringSource pour développer rapidement des applications Java. Par l’intermédiaire d’un shell, intégré à SpringSource Tool Suite, on peut en quelques commandes construire le squelette d’un projet, avec pojos et classes de tests, puis ajouter ensuite tout un ensemble de fonctionnalités liées à des frameworks tels que Spring MVC, Hibernate, JMS (la liste est longue)… Spring Roo s’appuie massivement sur les annotations et AspectJ pour générer les sources.

Parmi les nouvelles fonctionnalités:

• du reverse engineering incrémental à partir de la base de données. On génère les entités à partir de la base de données. Si le modèle évolue ensuite, les entités seront enrichies mais en gardant les éventuelles modifications que le développeur a pu ajouter depuis la dernière génération.
• des améliorations avec Spring MVC. Spring Roo utilise des fichiers JSPX (JSP XML compatible) au lieu de JSP ce qui lui permet à présent de pouvoir faire des aller-retours (round-trip) avec le modèle pour mettre à jour un champ par exemple.
• une meilleure intégration de GWT et de Google App Engine.
• une intégration de Apache Solr, le serveur de recherche derrière Apache Lucene, garantissant la réindéxation des éléments lorsqu’une entité est insérée, mise à jour ou effacée.
• des nouvelles annotations comme @RooJson qui ajoute deux méthodes de sérialisation/désérialisation à votre classe et @RooSerializable pour maintenir le serialVersionUID.

Le projet a lui-même subi des changements au niveau de son développement. Outre le passage à OSGI, ses sources sont maintenant sous Git (tout comme Hibernate récemment) et le projet a un nouveau logo. SpringSource a également mis à jour la plupart des librairies (JPA 2, Spring Framework, Spring Security, Spring Web Flow, Log4j, ActiveMQ, AspectJ et GWT).

Se plaçant comme une alternative à des outils comme Grails pour la haute productivité, il a le très grand avantage d’être full java. Par ailleurs, son shell, avec ses aides et ses complétions, est très réussi. A voir maintenant s’ils arrivent à convaincre plus de projets à migrer sur cette solution. Pour ceux qui aimerait en savoir plus, Spring Roo in Action va paraître chez Manning au printemps 2011.

Sortie de GWT 2.1

Après des mois d’attente, nous avons accueilli avec joie la sortie de GWT-2.1 jeudi dernier. Cette version arrive avec beaucoup de nouveautés; au menu un framework Editor, RequestFactory, MVP, Nouveaux widgets et bien plus. Bruce Johnson et son équipe ont voulu que cette version de GWT soit celle de la maturité. GWT 2.1 a pour objectif de bien répondre aux besoins des applications d’entreprise et les applications de haute scalabilité. C’est la version qui marie RAD, RIA et scalabilité.
Parmi les nouveautés on trouve:

• le framework Editor: Ce nouveau framework assure le binding entre les vues et le modèle. Vous aurez moins de code à écrire afin de peupler vos interfaces graphiques avec le contenu de vos POJO et vice versa.
• Le framework RequestFactory : Une alternative de GWT-RPC permettant de créer des applications CRUD. RequestFactory n’a pas pour but de remplacer GWT-RPC, mais plutôt de simplifier la mise en place de la couche d’accès aux données entre le client et le serveur.
• Le framework MVP (Places et activities): Enfin un framework interne qui implémente le pattern Model-View-Presenter en se basant sur les Places (notion de Lieu ou de place dans l’application) et les Activities (une activity c’est ce que peut faire un utilisateur dans une région de la page)
• Data présentation widgets (cell widgets): des composants orientés données ont été ajoutés toujours dans le but de permettre aux applications d’entreprises qui manipulent des millions d’enregistrements de faire des rendus rapides et efficaces (CellList, CellTable, CellTree, CellBrowser…).
• Sécurité: afin d’améliorer la sécurité des applications GWT, une nouvelle librairie voit le jour. Disponible sous le package com.google.gwt.safehtml et autour de l’interface SafeHTML. Cette librairie veut limiter les vulnérabilités liées au XSS (Cross-Site-Scripting).
• Logging coté client : java.util.logging est maintenant émulé dans le GWT-SDK il est désormais possible de créer des logs de la même manière que coté serveur et de les voir affichés dans une popup coté client. Les logs sont configurés non pas via fichier de propriétés mais plutôt via le descripteur .gwt.xml.
• SpeedTracer : passe d’un outil de monitoring côté client à un outil de monitoring client-serveur. Il est possible dorénavant de voir avec la même interface les performances du serveur et du client (s’appuyant entre autre sur Spring Insight).

D’autres nouveautés ont été apportées comme l’amélioration de l’intégration entre m2eclipse et le plugin Eclipse de Google (meilleure reconnaissance du classpath) et une intégration (plutôt moyenne à mon avis) avec Spring-roo…

Mozilla Rainbow: enregistrement audio et video dans le browser

Mozilla a récemment annoncé une nouvelle extension pour Firefox: Rainbow. Son rôle est de permettre au browser d’accéder aux capacités d’enregistrement audio & vidéo des ordinateurs et de les mettre à disposition à travers une API Javascript. Pour ce faire, Mozilla s’appuie sur des librairies cross-platform comme:

• Libvidcap pour l’accès au hardware vidéo
• Portaudio pour le hardware audio
• Vorbis et Theora pour l’encodage des flux audio et vidéo capturés

Mais l’intérêt de cette news réside peu dans l’extension elle-même qui est encore très loin d’être exploitable (ne fonctionne que sous Mac OS pour l’instant). Elle se situe plutôt dans la perspective apportée: il semble que l’on se dirige de plus en plus vers un monde où le navigateur aura accès aux matériels des machines. Lors d’un récent XKE (notre journée mensuelle d’échange) nous avions parlé de HTML5 vs Flash et l’un des problèmes que nous avions évoqué était que la technologie pour faire ne serait-ce qu’un simple chat vidéo en simple HTML/Javascript n’existait pas encore. Il semble maintenant que l’on s’en rapproche de plus en plus! Alors certes, ce n’est pas pour aujourd’hui… Ce n’est pas non plus pour demain car pour obtenir une API standard à plusieurs navigateurs, il faudra que les participants se mettent d’accord: Ericsson, par exemple, a commencé à jouer avec la balise device qui n’est pas encore standardisée et sur laquelle travaille le Whatwg, alors que l’implémentation de Mozilla semble ne pas passer par cette balise (du moins pour l’instant). Bref, on a le temps de voir arriver toutes ces bonnes choses, mais autant s’y préparer dès maintenant: le futur réside dans le navigateur !

Le coin de la technique

jOOQ 1.4.2, ou comment faire du SQL object

jOOQ, pour Java Oriented Object Querying, est un framework de persistance qui veut se démarquer des autres. En effet, son créateur Lukas Eder est parti de deux constats:

• le modèle relationnel est aujourd’hui quasi omniprésent dans les SI. De plus, le langage SQL nous permet de répondre à toutes nos attentes en terme d’interrogation de bases de données,
• une bonne partie des projets sur lesquels nous travaillons possèdent une base de données legacy dont il n’est souvent pas possible d’apporter quelconques modifications.

Mais alors pourquoi utiliser des outils de persistance complexes rajoutant une abstraction au SQL ? Question tout à fait légitime et pleine de bons sens.

Si vous êtes dans ce cas de figure, vous pouvez télécharger ce petit outil ici (même si vous ne l’êtes pas, je ne pense pas qu’il y ait d’inconvénient à ce que vous le testiez…). Puis, générez vos entités à partir de votre modèle relationnel en exécutant un générateur qui va parser votre base et détecter les entités ainsi que leurs relations. Ensuite, il vous suffira de créer vos requêtes en utilisant l’une des deux manières possibles. Voici un exemple pour illustrer ces propos:

Nous souhaitons exécuter la requête suivante avec jOOQ:

-- Select all books by authors born after 1920 from a catalogue:
SELECT *
FROM t_author a
JOIN t_book b ON a.id = b.author_id
WHERE a.year_of_birth > 1920
ORDER BY b.title

• Modèle objet:

// Instanciate your factory using a JDBC connection or datasource,
// and specify the SQL dialect you're using. Of course you can
// have several factories in your application.
Factory create = new Factory(datasource, SQLDialect.MYSQL);
// Create the query using generated, type-safe objects. You could
// write even less code with static imports!
SelectQuery q = create.selectQuery();
q.addFrom(TAuthor.T_AUTHOR);
q.addJoin(TBook.T_BOOK, TAuthor.ID, TBook.AUTHOR_ID);
q.addCompareCondition(TAuthor.YEAR_OF_BIRTH, 1920, Comparator.GREATER);
q.addOrderBy(TBook.TITLE);

• DSL SQL:

// Do it all "on one line".
SelectQuery q = create.select()
.from(T_AUTHOR)
.join(T_BOOK).on(TAuthor.ID.equal(TBook.AUTHOR_ID))
.where(TAuthor.YEAR_OF_BIRTH.greaterThan(1920))
.orderBy(TBook.TITLE).getQuery();

Ensuite, vous pourrez exécuter et récupérer vos résultats mapper sur vos objets grâce à jOOQ comme suit:

// Similar query, but don't join books to authors.
// Note the generic type that is added to your query:
SimpleSelectQuery q = create.select(T_AUTHOR)
.where(TAuthor.YEAR_OF_BIRTH.greaterThan(1920))
.orderBy(TAuthor.LAST_NAME).getQuery();
// When executing this query, also Result holds a generic type:
q.execute();
Result result = q.getResult();
for (TAuthorRecord record : result) {
    // With generate record classes, you can use generated getters and setters:
    String firstName = record.getFirstName();
    String lastName = record.getLastName();
    System.out.println("Author : " + firstName + " " + lastName + " wrote : ");
    // Use generated foreign key navigation methods
    for (TBookRecord book : record.getTBooks()) {
        System.out.println("  Book : " + book.getTitle());
    }
}

Enfin, l’API fournie permet d’exécuter des opérations de CRUD assez facilement:

// Create a new record and insert it into the database
TBookRecord book = create.newRecord(T_BOOK);
book.setTitle("My first book");
book.store();
// Update it with new values
book.setPublishedIn(2010);
book.store();
// Delete it
book.delete();

Vous trouverez tous les exemples cités ci-dessus sur le site officiel.

Plutôt sympa, ce framework démarre d’une idée intéressante en se situant entre les requêtes sql brutes via jdbc mais qui sont difficiles à maintenir et les frameworks tels que Hibernate ou iBatis, un peu trop haut niveau. Pour ne rien gâcher la roadmap du projet est visible ainsi que les tickets de bugs et l’avancement de chaque sprint, et bien que l’auteur soit seul sur ce projet, il le fait évoluer à un rythme soutenu.

Actualité éditeurs / SSII

• Sortie de RabbitMQ 2.0

Le coin de la technique

• Gestion automatique des ressources dans Java7 (ARM)

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

• Google et les brevets

Actualité éditeurs / SSII

Sortie de RabbitMQ 2.0

La sortie de la version 2.0 du serveur de messaging AMQP RabbitMQ vient d’être annoncée ici.
Cette release majeure vient avec une refonte importante et son lot de nouveautés :

• Une refonte de la gestion de la persistence permettant une alternative au moteur de persistence embarqué. Il sera possible de développer un support pour une base de données relationelle ou NoSQL ou tout autre data store.
• Le support de différents protocoles de messaging : AMQP (0-8 et 0-9-1), XMPP, STOMP, HTTP, SMTP… Il sera aussi possible d’ajouter de nouveaux protocoles à l’aide d’extensions.
• La mise en place d’une infrastructure ayant pour but de simplifier le développement d’outils pour la gestion et le monitoring de RabbitMQ.
• Une amélioration de la gestion des plugins (il n’est plus nécessaire de compiler les plugins, une version pré-compilée peut être directement chargée par RabbitMQ).

SpringSource qui a récemment racheté RabbitMQ (nous vous en avions parlé ici) propose de son côté un template reprenant les principes des templates jdbc, hibernate, jms ou encore LDAP encapsulant le client Java d’AMQP. Les utilisateurs habitués à JmsTemplate retrouveront donc leurs repères en utilisant l’AmqpTemplate du projet spring AMQP.

SpringSource/VMWare continue donc de faire évoluer son portefeuil de produits avec cette évolution majeure de RabbitMQ, qu’il considère comme une pièce essentielle à sa stratégie de développement du Cloud Computing (voir cet article de Rod Johnson).

Le coin de la technique

Gestion automatique des ressources dans Java7 (ARM)

Java7 suit son petit bonhomme de chemin sans qu’on ait encore une bonne visibilité sur la date de sortie officiel. Le build 105 de la version actuelle propose une nouvelle fonctionnalité très intéressante qui devrait facilité la vie de chaque développeur: l’Automatic Resource Management.

L’idée, proposée par Joshua Bloch depuis quelques années déjà, consiste à améliorer la fermeture des ressources sous la forme d’une clause try-with-resources. Actuellement lorsqu’on manipule une ressource, par exemple un InputStream, la façon la plus propre ressemble à ceci:

public void copyFile(File in, File out) {
    FileInputStream fis = null;
    FileOutputStream fos = null;
    try {
       fis = new FileInputStream(in);
       fos= new FileOutputStream(out);
       // Lire le fichier in et écrire dans le out
       ...
    }  catch (Exception e)  {
       ...
    } finally {
      close(fis);
      close(fos);
    }
}
private void close(Closeable closeable){
    if(closeable != null) {
        try{
           closeable.close();
        } catch(IOException e){...}
    }
}

Ce code devient vite très verbeux et répetitif car beaucoup de vérifications doivent être faites pour s’assurer de la possibilité de fermer la ressource. La solution pour simplifier cela est de déléguer la fermeture du flux à l’aide du try:

public void copyFile(File file) {
    try(FileInputStream fis=new FileInputStream(in);
        FileOutputStream fos=new FileOutputStream(out)) {
       // Lire le fichier in et écrire dans le out
       ...
    }
}

Le code gagne énormément en visibilité, les tests pour savoir si la ressource est null ou si la fermeture s’est bien déroulée sont gérés en interne de la JVM. A noter que pour être fermées les ressources devront étendre une nouvelle interface AutoCloseable.

S’il existe un certain consensus autour de l’utilité de cette évolution, il demeure encore un petit débat sur la partie catch des exceptions. Sans rentrer dans les détails, les exceptions levées pendant la fermeture d’une ressource annihilent celles levées dans le bloc try, ce qui en général est préférable mais du coup peut aussi masquer des exceptions importantes pour l’analyse du problème.

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

Google et les brevets

Semaine chargée pour Google:

• InfoQ nous annonce que le MPEG LA a décidé de continuer à ne pas réclamer de royalties pour les videos encodées en H.264 et distribuées gratuitement aux utilisateurs. Seules les plateformes vendant des vidéos sont, elles, toujours soumises à taxation. C’est donc une réponse à Google qui avait il y a quelques temps annoncé WebM, un codec vidéo semblable au H.264 mais plus libre et débarrassé des problèmes de brevets et de royalties qui entravent ce dernier. Si InfoQ ne voit pas trop de problèmes à continuer d’utiliser H.264, ce n’est pas du tout l’avis de Mike Shaver ingénieur haut gradé chez Mozilla et qui rappelle que les logiciels permettant de produire ou de consommer ces vidéos devront eux toujours s’acquitter d’une licence. La bataille entre WebM et H.264 ne fait donc que commencer.
• Ensuite, c’est Paul Allen, le co-fondateur de Microsoft, qui attaque Google et nombre de ses petits camarades (AOL, Yahoo, Facebook) pour avoir enfreint 4 brevets détenus par sa compagnie « Interval Licensing ». Le blog Digits du Wall Street Journal s’est penché sur 2 de ces brevets. Nous vous déconseillons fortement la lecture de son analyse si vous avez réalisé quoi que ce soit dans l’informatique ces 10 dernières années. En effet, vous risquez de ne plus trouver le sommeil en vous rendant compte que vous enfreignez sans doutes, vous aussi, nombre de brevets !
• Et pour finir sur Google et les brevets, vous vous souvenez des récentes poursuites engagées par Oracle concernant Java et Android. Google vient de riposter, en annoncant qu’aucun de ses employés ne participera à JavaOne cette année. Pour ceux qui voulaient échanger avec les employés de Google, il semble que c’est plus tard dans l’année, à Devoxx, qu’il faille se rendre. Mais rassurez vous, il y aura quand même de l’ambiance à JavaOne: James Gosling, père de Java, demande sur son blog à toute personne y assistant de porter un TShirt arborant le slogan « Java just Free it ». Si cette idée ne risque pas trop de faire bouger Oracle, elle devrait quand même apporter sa dose de fun à l’évènement !

Actualité éditeurs / SSII

• SpringSource se dote d’un cache distribué

Le coin de la technique

• Jarlsberg, la sécurité en s’amusant
• Multi-Catch confirmé dans le projet Coin

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

• C’est le printemps, les User Groups fleurissent

Actualité éditeurs / SSII

SpringSource se dote d’un cache distribué

VMware vient de faire l’acquisition de la société GemStone Systems, éditeur de la solution de cache distribué GemFire. Elle sera gérée désormais sous la houlette de SpringSource. Ce nouveau rapprochement s’inscrit dans la stratégie affichée de la firme de fournir une plateforme complète de cloud destinée aux applications Java.

Par ailleurs, dans une interview donnée à InfoQ, Rod Johnson affirme que le framework Spring développera les abstractions nécessaires à l’intégration de ce type de produit, comme c’est déjà le cas pour les RDBMS, les broker JMS, etc via les Templates Spring, et pourrait permettre l’intégration d’autres solutions de data-grid comme Oracle Coherence ou encore Terracotta.

Le coin de la technique

Jarlsberg, la sécurité en s’amusant

Xss, DoS, Xsrf… Des acronymes barbares qui désignent des failles de sécurité courantes dans nos applications Web. Si vous voulez mieux les connaitre, et ainsi vous en protéger, le nouveau projet de Google Labs, Jarlsberg (fromage norvégien), est pour vous.
Et comme le meilleur moyen d’apprendre est de faire, Google met à votre disposition un site truffé de failles de sécurité que vous pourrez hacker à loisir.
Les failles sont organisées en fonction de leur type :

• Cross-site Scripting (XSS)
• Cross-site Request Forgery (XSRF)
• Cross-site Script Inclusion (CSSI)
• Manipulation de l’état du client
• Traversée d’arborescence
• Déni de Service (DoS)
• Exécution de code
• Vulnérabilité de la configuration
• Vulnérabilités AJAX

Pour venir à bout de ces failles, il existe trois types de tests :

• Tests boite noire : l’utilisateur ne connait pas le fonctionnement interne du site, il tente de hacker le site en passant par les pages exposées
• Tests boite blanche : le code de l’application en python est connu par le hacker
• Tests boite grise : un panaché des deux précédentes méthodes

Ces tests sont servis pour une large variété d’outils de hacker :

• Snippets HTML
• Upload de fichier
• Administration du site
• création de nouveaux comptes utilisateur
• Language de templating Jarlsberg
• Injection AJAX

L’approche est très pédagogique, avec une succession de challenges à résoudre. Par exemple, le premier de ceux ci : pouvez vous uploader sur le site un fichier qui vous permettra d’exécuter un script sur le serveur d’application ? Chaque challenge propose des indices, une manière d’exploiter la faille et une correction.
Une plongée passionnante dans l’univers des hackers.

Avant de vous lancer dans ce Google Lab, nous vous conseillons la lecture de l’article de Christian Heilmann.

Bien sûr, ces trucs et astuces ne doivent pas être reproduits à la maison, vous pourriez tomber sous le coup de la loi.

Multi-Catch confirmé dans le projet Coin

Finalement, après plusieurs hésitations, Joe Darcy confirme la possibilité de rassembler plusieurs catch d’exceptions dans une même clause dans Java 7. Ainsi il sera possible d’écrire:

try{
// code
} catch (ExceptionA|ExceptionB ex){
// code
}

Les discussions portaient sur la deuxième partie de cette proposition, le renvoi ( rethrow ) des exceptions. En effet il peut arriver qu’une exception soit renvoyée après avoir été attrapée. Dans ce cas elle doit apparaître dans la signature si c’est une exception vérifiée ( checked ). Par exemple :

public void myMethod() throws Exception {
try{
// A hérite d'Exception
throw new A();
} catch (Exception e){
// code: par exemple un log
throw e;
}
}

Ce que propose le projet Coin, c’est de vérifier les exceptions possibles dans le bloc try et de donner la possibilité dans la signature de la méthode de renvoyer le type précis des exceptions. Pour cela on utilise le modifier final. Ce qui donne :

public void myMethod() throws A {
try{
// A hérite d'Exception
throw new A();
} catch (final Exception e){
// code: par exemple un log
throw e;
}
}

Ceci permet d’avoir une signature plus précise et de pouvoir remonter une exception facilement. Les difficultés de cette proposition ont tourné autour du type d’exception qui se trouve dans la clause catch dans le cas où le type n’est connu qu’au Runtime.

Cette proposition en ravira plus d’un mais fera aussi sourire ceux qui prônent la suppression des exceptions vérifiées. Pour finir, un petit cas limite amusant de cette proposition, relevé par Stephen Colebourne :

public void myMethod() {
try{
//  du code sans exception
} catch (final Exception e){
// on envoie une exception vérifiée qui n'est pas dans la signature!
throw e;
}
}

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

C’est le printemps, les User Groups fleurissent

Avec notre plateforme de prédilection, Java, qui s’ouvre de plus en plus à de nouveaux langages, il fallait bien que la communauté suive. Nous assistons donc ces derniers temps à l’éclosion de nouveaux User Groups. Le premier à bourgeonner fut le Scala User Group (attention, pas « SUG » car le nom est déjà pris) qui a pris ses racines lors de la soirée Scala organisée par le Paris JUG. Cette semaine, c’est Guillaume Laforge, Groovy project lead et Cast Codeur émérite, qui a annoncé sur la mailing liste du Paris JUG la création du Groovy User Group. La première rencontre est d’ores et déjà prévue le 10 juin.
Ces nouveautés s’inscrivent dans la lignée de ce que nous avons déjà observé avec la multiplication des JUGs: la communauté s’organise pour partager, lier connaissance et évoluer. Après les différents JUGs centrés sur Java, il n’est pas étonnant de voir des User Groups se créer pour rassembler les personnes intéressées par les nouveaux langages de cette plateforme.
Par la suite, ces langages resteront-ils sous la coupe des divers JUGs ou allons nous assister à la création du « Marseille Groovy User Group » ou du « Lyon Scala User Group » ?

Actualité éditeurs / SSII

• TC Server spécial printemps

Le coin de la technique

• Html5 en action
• soapUI s’enrichit du support de JMS et AMF
• Des tests unitaires expressifs grâce à Spock
• JBoss simplifie les tests dans les conteneurs EJB

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

• Salon « Solutions Linux Open Source »

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

TC Server spécial printemps

Plus besoin de vous présenter Spring TC Server dont nous avons déjà parlé plus d’une fois sur le blog. Pour mémoire, TC Server est un Tomcat intégré à la sauce Spring. La nouveauté de la semaine vient de l’annonce d’une édition spéciale du TC Server 2.0 pour le printemps. Le TC Server Spring Edition est annoncé pour Avril et déjà mis à disposition des développeurs via la Developer Edition. L’offre TC Server se répartit donc maintenant en trois éditions différentes:

• L’édition standard qui intègre l’offre de base TC Server (Administration, Déploiement, Diagnostic par Thread et Heap dump).
• L’édition spring ajoute à la première offre, le monitoring automatique des applications déployées.
• L’édition developer intègre TC Server dans Spring Tool Suite pour que les développeurs puissent surveiller en temps réel les performances de leurs applications.

C’est aussi l’occasion pour SpringSource de fournir une bonne intégration avec les solutions VMWare pour déployer et tester facilement sur des machines virtuelles. Pour notre bonheur à tous, SpringSource inscrit donc durablement son TC Server dans le paysage des serveurs J2EE et continue à participer activement au développement de Tomcat.

Le coin de la technique

Html5 en action

Comme une suite logique à notre article HTML5, les nouveaux éléments, DevelopperWorks propose un tutoriel HTML5 + CSS3. Après quelques rappels succincts sur ces deux standards, Joe Lennon propose de soumettre quelques unes de ces nouveautés à l’épreuve du feu. Un survol relativement complet, puisqu’il couvre la nouvelle structure de page, quelques nouvelles balises sémantiques, la vidéo, CSS3, les nouveaux formulaires et le canvas. Un complément intéressant pour tous ceux qui étaient impatients de découvrir ces nouvelles possibilités.

soapUI s’enrichit du support de JMS et AMF

Le célèbre outil de test de WebService, SoapUi, poursuit sa marche en avant, et ajoute de nouvelles cordes à son arc. La version 3.5 offre de nouvelles fonctionnalités particulièrement utiles aux développeurs travaillant sur des architectures web complexes, en particulier le test des ressources JMS.
Les développeurs de chez EviWare n’ont pas réinventé la roue, et ont seulement intégré un framework robuste sur ce sujet, HermesJMS. A vous les joies de poster / recevoir des messages JMS (texte ou xml), de manipuler les headers, de scripter vos files, et surtout d’automatiser vos tests d’intégration facilement.
De manière plus anecdotique (à notre sens en tout cas), cette nouvelle version propose aussi un ensemble d’outils pour tester vos ressources JDBC.
Enfin, dernière évolution majeure que nous n’avons pas eu l’occasion de tester, mais qui semble prometteuse, la possibilité de tester vos scripts AMF (Flash et Flex).
Tous les tutoriels se trouvent dans la page de la release 3.5 (qui ne va bien sûr pas sans son lot de corrections de bugs).

Des tests unitaires expressifs grâce à Spock

Spock est une petite librairie de tests unitaires en Groovy permettant d’écrire un test sous le format spécification (le format given/when/then est aussi supporté) :

def "subscribers receive published events at least once"() {
      when: publisher.send(event)
      then: (1.._) * subscriber.receive(event)
      where: event << ["started", "paused", "stopped"]
    }

La version 0.4 apporte la notion de « Data tables ». On retrouve cette notion dans d’autres API (notamment testNG). Cependant l’apport de Groovy rend le test vraiment très expressif :

def "maximum of two numbers"() {
  expect:
  Math.max(a, b) == c
  where:
  a | b | c
  3 | 7 | 7
  5 | 4 | 5
  9 | 9 | 9
}

Une petite librairie sympathique à découvrir ici.

JBoss simplifie les tests dans les conteneurs EJB

JBoss vient d’annoncer une première version alpha d’un nouveau projet baptisé Arquillian. Ce projet permet de simplifier l’écriture de tests unitaires qui doivent s’exécuter au sein d’un conteneur EJB. S’il est parfaitement possible de tester un session bean hors conteneur depuis l’arrivée de Pojos dans EJB 3.0, disposer d’un conteneur EJB permet de simplifier les injections de dépendance qui doivent être réalisées via l’annotation @EJB ainsi que les accès à des ressources propres au conteneur.

Conscient de cette problématique, pour laquelle l’univers Spring offre de nombreuses solutions, JBoss tente depuis plusieurs années d’apporter une réponse satisfaisante aux développeurs. Cette quête s’est engagée dès le développement des première versions de son conteneur EJB 3.0 avec le développement d’une déclinaison pouvant être démarrée depuis des tests et nommée Embeddable EJB (renommée depuis JBoss Embedded AS) ; cette initiative avait par ailleurs permis d’embarquer un conteneur EJB 3.0 dans Tomcat. Aujourd’hui Arquillian va plus loin en proposant une API de plus haut niveau pour tester ses EJB : l’ensemble des fastidieuses tâches de démarrage du conteneur sont ainsi masquées et le développeur n’a plus qu’a décrire son besoin.

Le projet est pour le moment à un stade embryonnaire et il faudra probablement plusieurs mois avant que l’on dispose d’un ensemble cohérent pour l’utilisation au sein des projets EJB. Toutefois, le souhait affiché d’utiliser Arquillian pour les tests internes de Seam 3 et pour les TCK de Weld permet d’espérer une rapide évolution pour cette API.

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

Salon « Solutions Linux Open Source »

Le salon « Solutions Linux Open Source » se déroulera cette semaine à la Porte de Versailles. De nombreux exposants y seront présents tels Oracle, Linagora, Alter Way, Canonical et bien d’autres encore… C’est l’occasion d’assister à de nombreuses conférences dont celles qui nous semblent les plus intéressantes sont:

• Oracle et l’open source
• Progiciels, le logiciel libre envahit le domaine fonctionnel
• Virtualisation: retours sur investissement et bonnes pratiques de la virtualisation
• Mobilité: smartphones, le libre prépondérant ?
• Développement logiciel collaboratif : bonnes pratiques, premiers bilans
• Meilleures pratiques pour l’intégration continue et méthodes agiles avec : Subversion, Ant, Maven et CruiseControl

De nombreuses formations seront aussi dispensées, mais par contre, elles sont payantes. L’an passé, c’est surtout l’omniprésence des solutions de virtualisation qui nous avait marqué. Quel sera le thème majeur du salon cette année ?

Actualité éditeurs / SSII

• dm Server 2.0 transféré de SpringSource à Eclipse
• HornetQ 2.0, un véritable renouveau ?
• Nexus sous license GPL: Sonatype explique son choix

Agilité

• Le rôle des leaders dans une équipe agile

RIA

• Le nouveau jQuery est arrivé !
• Survol de la galaxie Flex.

Actualité éditeurs / SSII

dm Server 2.0 transféré de SpringSource à Eclipse

SpringSource annonce cette semaine la finalisation de dm Server 2.0. Il s’agit là d’une mise à jour importante qui agit principalement sur la réduction des nuisances causées au développeur de par la nature même d’OSGi. En effet, si beaucoup peuvent s’accorder sur le fait que la modularité dynamique peut constituer un intérêt sur de nombreux projets, c’est le coût en nuisances et en lourdeurs qui fait que cette solution n’est toujours pas très populaire au sein des applications d’entreprise. L’enjeu est donc crucial puisqu’il s’agit maintenant pour SpringSource de rendre attractif son serveur modulaire pour les entreprises. Un an et demi après le lancement du projet l’évolution de cette version 2.0 sera donc à suivre…

Parallèlement, SpringSource annonce le transfert de dm Server au sein de la fondation Eclipse. Il tiendra alors le rôle d’implémentation de référence de la spécification BluePrint OSGi 4.2 récemment finalisée. Tout comme le travail de simplification apporté à la nouvelle version, la standardisation permettra de rassurer les entreprises sur la pérennité de la technologie proposée par dm Server, qui restait jusqu’alors propriétaire.

HornetQ 2.0, un véritable renouveau ?

Pour mémoire, HornetQ est le nouveau nom de JBoss messaging. En bref, c’est pour le moment un projet Open Source sans support ayant vocation à s’intégrer dans le futur aux produits d’entreprise RedHat. Nous en parlions déjà en aout l’année dernière. La roadmap visait alors clairement la mise à disposition d’une API de messaging RESTful. Malheureusement, il n’y en a même pas l’ombre pour le moment et cela reste dans la roadmap. Gageons que quelques problèmes d’architecture accompagnés de bugs bloquants ont empêché le développement de cette nouvelle fonctionnalité.

L’annonce reprend principalement la précédente et ne liste rien de neuf par rapport à Aout 2009. Mais s’il y a bien dans le Jira du projet un grand nombre de bugs corrigés, c’est surtout la maturité du source qui a grandi.
Malgré tout, la bonne nouvelle est que JBoss espère bien pouvoir l’intégrer dans sa ligne produit et que RedHat continue l’investissement sur le projet.

Nexus sous license GPL: Sonatype explique son choix

Nexus est le gestionnaire de dépôts Maven développé par Sonatype. La version 1.0 est sortie à l’été 2008 sous la licence GPL. Il faut croire que Sonatype a fait face à de nombreuses critiques car la société vient de publier sur son blog un post intitulé « Why we chose the GPL for Nexus » lui permettant d’argumenter son choix. Alors quelles furent ces raisons ?
Le « problème » de la GPL est qu’elle force à redonner à la communauté les changements effectués dans le source au cas où le logiciel obtenu est redistribué. Dans le cas spécifique de Nexus, Sonatype explique que le produit était vu dès l’origine comme un produit commercial, sans question d’open source. Puis, trouvant le processus de développement plus fun, intéressant et plus productif, couplé au fait que l’équipe voulait « protéger son investissement », il fut décidé de passer en Open Source. Sonatype est franc sur ce dernier point et affirme l’avoir toujours été.
Ensuite, la société explique les idées qui guident généralement ses choix de licence:

• L’Affero GPL ne permet pas aux utilisateurs de développer des extensions, même à usage interne, sans avoir à redistribuer les sources. Dans le cas de Nexus, cela aurait sans doute impacté négativement son adoption.
• Sonatype considère que, pour un projet open source, passer d’une licence donnée à une licence plus restrictive n’est pas correct. On se souvient que certains on déjà réalisé cette transition en s’attirant alors des critiques d’utilisateurs. Sonatype déclare que ce ne sera pas leur cas.
• La documentation, elle, est soumise à un principe différent. En effet, la compagnie pense que celle-ci constitue une bonne partie de la plus-value apportée. Ainsi, ils ne veulent pas voir de concurrents se servir de leur travail. C’est pourquoi ils ont choisi la licence Creative Common 3.0 BY-ND-NC interdisant à quiconque de modifier cette documentation.

Au final, cet article est passionnant dans la mesure où il nous permet de bien appréhender le raisonnement derrière le choix d’une License pour des produits très répandus dans l’écosystème Java. Nous les utilisons tous les jours sans forcément nous poser de questions. Pourtant, pour certains clients, il peut être important de garder fermées leurs sources. Après, savoir si c’est une réelle nécessité ou un simple état d’esprit difficile à changer est une autre histoire !

Agilité

Le rôle des leaders dans une équipe agile

Mike Cohn, auteur de nombreux livres sur l’agilité et membre fondateur de l’Alliance Agile, revient sur le rôle des managers au sein d’une organisation de type agile. Un des principes forts des méthodes agiles est la mise en place d’une équipe auto-organisée, où il n’y a théoriquement plus de chef de projet. Cependant, Mike nous averti qu’une auto-organisation ne veut pas dire les développeurs font tout ce qu’ils veulent. Au contraire, Mike explique que des managers ont tout à fait leur rôle à jouer dans ce type d’organisation. Ainsi, il développe l’idée d’une influence subtile et indirecte des managers sur l’équipe.
C’est alors au fur et à mesure des challenges, des échecs et réussites que l’équipe évolue d’elle-même vers l’organisation la plus appropriée. Les managers sont néanmoins là pour poser certaines limites et contraintes.
A la fin de son article, Mike nous présente un exemple concret d’un scrum master au prise avec un développeur, qui est un peu trop solitaire, et nous expose comment il pourrait résoudre ce problème de manière subtile. Le scrum master peut être alors vu comme un agitateur au sein de l’équipe pour l’aider à devenir plus agile. Et, c’est là l’un des plus gros challenges d’un scrum master, qui consiste à naviguer entre un subtil mélange de contrôle et d’influence.

RIA

Le nouveau jQuery est arrivé !

Un an jour pour jour (ou presque) après la sortie de jQuery 1.3, voici venir la nouvelle mouture du framework qui nous arrive dans une version 1.4. Le détail complet des nouveautés se trouve sur cette page. Le mot d’ordre : performance !

L’API a subit une réécriture complète. Un des points marquants est la fonction live(), déjà présente dans la version précédente, qui supporte désormais tous les évènements Javascript (click, change…). Pour ce qui est des nouveautés au niveau de l’API, on retiendra plus particulièrement :

• contains() : vérifie l’existence d’un nœud DOM dans un autre nœud DOM,
• isEmptyObject() et isPlainObject() : vérifie si un objet est vide ou existant (new Object ou {}),
• detach() : supprime du DOM un set d’éléments,
• focusin() et focusout() : ajoute un événement de type focus,
• clearQueue() : supprime de la pile les éléments qui n’ont pas encore été lancés,
• delay() : définit un timer pour l’exécution de certains éléments dans la pile,
• toArray() : récupère tous les éléments du conteneur jQuery dans un tableau.

Côté performance, on peut noter une réelle amélioration pour les méthodes remove, html et empty. Un gros travail a donc été effectué au niveau des méthodes de manipulation du DOM. Il en va de même pour la gestion des attributs et des propriétés css.

Pour le téléchargement de la librairie production (minifié et GZippé) ou développement (code non compressé) ou pour consulter la documentation, je vous renvoie directement sur la home page du site. Et pour les fans de CheatSheet (comme moi ), la version 1.4 est déjà disponible au format HTML, PDF ou PNG.

Et si vous appréciez jQuery et le travail de toute l’équipe qui se trouve derrière, vous pouvez faire une donation de 20$ et ainsi recevoir un eBook jQuery gratuitement !

Survol de la galaxie Flex.

Vous voulez passer à Flex, mais vous ne savez pas par où commencer ? Suivant l’adage « Pour bien travailler il faut avoir de bons outils », InfoQ propose un survol de la galaxie Flex. Sans rentrer dans les détails de l’article, on notera :

• les IDE : le célèbre FlexBuilder, mais aussi IntelliJ, ou encore des environnements plus exotiques comme Amethyst, EnsembleTofino et FlashDevelop. Nous n’avons pas (encore) eu l’occasion d’essayer ces derniers, mais si l’un de nos lecteurs possède une expérience avec ces outils, qu’il n’hésite pas à la partager !
• les frameworks : là encore, outre les classiques (PureMvc, Cairgorm…), quelques petits nouveaux tentent d’émerger, dont deux qui nous ont interpellé : Ruboss (pour intégrer Ruby on Rails) et Prana (IoC). Nous espérons bientôt les tester.
• les outils de support du developpement : là encore, Flex commence à se doter d’un arsenal conséquent : tests unitaires (FlexMonkey), couverture de code (FlexCover), tests de GUI (RIATest). Il ne reste plus qu’à monter une usine logicielle digne de ce nom en agrégeant ces utilitaires.
• les outils d’intégration dans l’entreprise : là encore, un certains nombre de ces outils sont archi-connus (comme BlazeDs), et d’autres plus confidentiels, peuvent présenter un réel intérêt : intégration à Struts (FxStruts), AmFast (Python)… Nous aurons probablement l’occasion d’en reparler.

Au final, InfoQ propose un survol relativement complet et permet de découvrir de nouveaux outils. Ne reste plus qu’à les tester, ou à recueilli vos retours d’expérience !

Actualité éditeurs / SSII

• SpringSource et Oracle ensemble pour l’OSGi d’entreprise

Le coin de la technique

• Lucene passe à Java 5
• Mark Reinhold justifie l’introduction des closures
• Patterns NoSQL

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

• Devoxx 2009 : le bilan

Actualité éditeurs / SSII

SpringSource et Oracle ensemble pour l’OSGi d’entreprise

Adrian Colyer, SpringSource, a annoncé la création d’un nouveau projet au sein de la fondation Eclipse : Gemini. Il s’agit d’un sous-projet d’Eclipse Runtime qui a pour but de réunir l’ensemble des implémentations de référence des spécifications OSGi liées au monde de l’entreprise. Il s’agit d’un effort commun de SpringSource et d’Oracle.

Deux composants fondamentaux sont apportés par SpringSource :

• Gemini Web Container : il permet le fonctionnement d’un conteneur de Servlets dans un environnement OSGi. Cette implémentation est actuellement utilisée dans SpringSource dm Server et est donc prévue pour fonctionner sur Tomcat. Mike Keith, Oracle, assure que l’adaptation pour Jetty arrivera par la suite grâce à une collaboration avec l’équipe de ce projet.
• Gemini Blueprint Service : il s’agit de Spring Dynamic Modules. Ce projet, qui a fortement inspiré la spécification du Blueprint Service intégré à OSGi 4.2, devient logiquement son implémentation de référence.

Il est important de noter qu’Adryan Colyer explique que SpringSource continuera désormais le développement de ces deux projets directement au sein de la fondation Eclipse et non plus en interne.

Oracle, pour sa part, apporte plusieurs implémentations de référence pour des RFC supplémentaires non intégrées à la spécification OSGi 4.2 : RFC 98 (transactions), RFC 122 (database access), RFC 139 (JMX integration), RFC 142 (JNDI integration), RFC 143 (JPA integration), RFC 146 (JCA integration).
Mike Keith indique qu’EclipseLink est à même de fonctionner correctement avec OSGi depuis longtemps, mais qu’il n’implémentait pas JPA lorsque cette intégration a été mise en œuvre au sein du projet. Par conséquent, une adaptation est nécessaire pour passer à la RFC 143, afin d’assurer une intégration JPA standard.

Alors que la spécification 4.2 a été finalisée il y a 2 mois, les implémentations de référence étaient toujours attendues. Cette réunification des implémentations liées a l’OSGi d’entreprise au sein d’un même projet Eclipse est une excellente nouvelle : elle met en avant la standardisation dont on pourra désormais bénéficier pour les développements intégrant OSGi dans les applications JEE. Mais cela suffira-t-il à démocratiser OSGi en entreprise ?!

Le coin de la technique

Lucene passe à Java 5

L’équipe du projet Lucene annonce la sortie de Lucene 3.0. Comme nous l’expliquions précedemment, cette version marque une évolution majeure puisqu’elle est la première a nécessiter Java 5.0 au minimum.

L’API bénéficie donc désormais de l’ensemble des améliorations du langage de Java 5.0 dont les generics, le varargs, les enums et l’autoboxing.

Tempérons cette annonce : l’API Lucene n’a pas été refondue, il ne s’agit que de quelques améliorations visant à la rendre type-safe. Citons par exemple :

• Apparition d’enums BooleanClause.Occur, Field.Index, Field.Store et Field.TermVector ; ces concepts étaient jusqu’alors représentées sous forme de constantes type-safe.
• La méthode getFields() de la classe Document retourne désormais une List<Fieldable> alors qu’elle retournait une simple List jusqu’alors.
• La classe Term implémente désormais Comparable<Term> et non plus simplement Comparable.

Ces changements légers décevront peut-être certains utilisateurs lassés par l’API vieillissante de Lucene, mais on appréciera toutefois la facilité de migration, puisqu’il s’agira la plupart du temps de supprimer quelques casts (l’équipe Lucene cite quelques cas à surveiller lors de la migration).

Cette nouvelle version, qui apporte par ailleurs quelques modifications mineures, conclut donc un cycle d’évolutions importantes sur le projet Lucene.

Mark Reinhold justifie l’introduction des closures

C’était l’Annonce de cette édition de Devoxx, l’apparition des closures en Java 7. Mark Reinhold revient, sur son blog, sur les raisons à l’origine de cette petite bombe.
Il justifie cette évolution majeure du langage par la nécessité pour Java de tirer partie des nouvelles générations de processeurs, multi-cœurs.
Jusqu’ici, pour exploiter cette puissance, il fallait utiliser des Parallel Array et tout le code inutile nécessaire à leur fonctionnement. Les closures permettent de supprimer ce code, et il est temps de les introduire en Java.
Java doit se concentrer sur deux fonctionnalités clés : la syntaxe littérale, et les fonctions typées. L’arrivée des closures requiert deux autres évolutions de Java : les conversions, et l’extensibilité des méthodes.
Il est temps pour Mark Reinhold d’oublier les querelles. Sun spécifiera et implémentera un premier jet des closures pour le JDK 7. Cela permettra une expérimentation à grande échelle, et si tout se passe bien, cela conduira à une JSR de modification du langage, qui pourra être incluse dans Java SE 7.
La tâche est immense et Mark Reinhold appelle bien évidement toutes les bonnes volontés à contribuer.

Bien au-delà de la manipulation du multi-threading, les closures pourraient permettre une simplification des APIs courantes. Cette perspective semble essentielle à Mark Reinhold qui ne pouvait attendre le JDK 8 pour une nouvelle tentative, dans 3 à 4 ans…

Patterns NoSQL

Nous vous parlions récemment dans une revue de presse et un article du mouvement NoSQL, qui se caractérise par « une absence de requête et par un relâchement des caractéristiques ACID propres aux RDBMS ». Ricky Ho, architecte chez Adobe, revient sur son blog sur les caractéristiques communes de plusieurs technologies permettant de « faire du NoSQL », et extrait quelques patterns récurrents. Ne vous arrêtez pas à la mise en page étriquée de l’article, car la description est très complète. Ricky Ho y explore successivement:

• Les types de noeud possibles (physiques et virtuels) ainsi que leur fonctionnement.
• Le partitionnement des données.
• La réplication de ces données, ainsi que le maintien de leur consistance.
• La gestion des pannes.

On notera quand même que l’une des solutions retenue pour le stockage des données reste… une base de donnée relationnelle ! Humour mis à part, une telle formalisation de patterns est vraiment bienvenue dans un environnement aussi émergeant.

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

Devoxx 2009 : le bilan

Nous concluons aujourd’hui notre série de billets sur Devoxx 2009. Ces 5 jours passés à Anvers furent riches en informations et en rencontres et nous souhaitions vous les faire partager.

A l’heure du bilan, voici ce que nous retiendrons de cette édition :

• Les annonces concernant JDK 7, JEE 6 et Maven 3.0.
• Le succès de JEE 6 : toutes les sessions sur le sujet ont fait salle comble.
• La place réservée à la nouvelle plateforme Flash d’Adobe, présente au keynote et dans de nombreuses sessions ; il est intéressant de noter que cette place correspond exactement à celle occupée par JavaFX lors de la précédente édition.
• L’omniprésence de Scala ; au-delà des sessions qui lui étaient consacrées, il était cité dans beaucoup d’autres présentations lorsqu’il était question de DSL par exemple.
• L’intérêt persistant de la communauté pour le Cloud Computing. Ce nouveau concept a rencontré un large succès à Devoxx.

Pour rentrer plus en détails dans les enseignements de cette conférence, vous pouvez désormais retrouver l’intégralité de nos billets Devoxx :

• Devoxx – Jour 1 – Adobe University
• Devoxx – Jour 1 – Applications robustes avec Amazon EC2
• Devoxx – Jour 1 – Kanban in action
• Devoxx – Jour 1 – JSF 2
• Devoxx – Jour 1 – NoSQL avec HBase
• Devoxx – Jour 2 – Google App Engine
• Devoxx – Jour 2 – Les effets avec Flex 4
• Devoxx – Jour 2 – Hibernate Search
• Devoxx – Jour 2 – Java FX The developer guide
• Devoxx – Jour 2 – SOA en pratique
• Devoxx – Jour 2 – Scala Actors
• Devoxx – Jour 3 – Spring Actionscript
• Devoxx – Jour 3 – ScalaTest
• Devoxx – Jour 3 – La keynote
• Devoxx – Jour 3 – JEE6
• Devoxx – Jour 4 – Maven Reloaded
• Devoxx – Jour 4 – Java Performance Tuning
• Devoxx – Jour 4 – Intégration pour le Web avec iBeans
• Devoxx – Jour 5 – Projet Lombok

Les grands thèmes du jour :

• Présentation de Spring 3.0 et de la roadmap SpringSource.
• Amélioration de la productivité avec Spring ROO.
• Standardisation et positionnement stratégique et face à Java EE.
• Cloud Computing avec le nouveau mouvement lancé par le rachat de SpringSource par VMWare.

Dans ce cadre, j’ai eu l’occasion de mener une interview d’Arjen Poutsma en marge des présentations (merci Michael). Ce billet retrace ce que j’ai retenu de cet entretien.

Arjen Poutsma est le créateur de Spring WS, projet sur lequel il est d’ailleurs toujours largement impliqué. C’est également le second committeur Spring 3.0 avec Juergen Hoeller, qui était venu l’an passé pour présenter le sujet.

Toutes les nouveautés Spring 3.0 abordées lors de la conférence n’ont pas été traitées lors de l’entretien. Cet article n’a pas pour but de les cataloguer, même si certaines d’entre elles y sont abordées …

Date de sortie de Spring 3.0 et le communiqué de presse récemment publié

À l’heure actuelle, le développement de l’ensemble des fonctionnalités que SpringSource voulait inclure dans Spring 3.0 est terminé, le code est complet et pleinement documenté. C’est Spring 3.0 RC1 est sortie en octobre.

Avant la sortie officielle prévue en décembre, une RC2 va sortir pour corriger les quelques jira restées ouvertes

Vous pouvez commander votre version Spring 3.0 pour Noël.

Spring 3.0, ce n’est pas un petit projet

Le projet est porté par Juergen Hoeller et Artjen Poutsma, qui en sont également les deux plus gros contributeurs. En plus de cela, de nombreux committeurs externes (environ 15 personnes) ont participé au projet, mais pas à plein temps. Le projet a commencé il y maintenant plus d’un an, ce n’est pas un petit projet. En plus des nouvelles fonctionnalités offertes par Spring 3.0, le gros du travail a résidé dans la réécriture et la simplification de Spring core. Un temps non négligeable a été passé pour aligner ou préparer les mises à jour des autres modules Spring. Un travail d’uniformisation des numéros de version est également en cours pour simplifier les interdépendances entre les différents projets. En effet, il devenait difficile de dire que Spring WS 1.5.8 est compatible avec Spring 2.5.x alors que la 1.5.9 n’est compatible qu’avec Spring 3.0. À l’image de Spring Sécurité, les principaux modules Spring devraient donc passer rapidement en 3.0.

Migrez à Spring 3.0 en 2 minutes chrono

Durant les présentations, Adrian Coyler et Arjen ont tous deux affirmé que Spring 3.0 était 100% rétro-compatible avec Spring 2.5. Arjen a même décrit le processus de migration comme une simple mise à jour de jars. Au-delà de la jolie phrase marketing qui fait sourire, un effort particulier a été apporté à la conservation de cette rétro-compatibilité. Les fonctionnalités Core restent complètement rétro-compatibles, voire inchangées. En revanche, si vous migrez un gros projet, vous tomberez probablement dans des cas d’utilisation spécifiques vous obligeant à modifier quelques petites choses. Difficile d’assurer que l’ensemble des cas d’utilisation sont rétro-compatibles (vu leur nombre), même si la plus grosse partie des ré-écritures concerne des classes de tambouille internes à Spring.

Message personnel pour Julien (Dubois) : Arjen m’a proposé d’offrir gracieusement tes services à mon client si la migration me prend plus d’une journée. On lance les paris ?

D’autre part, Spring prônant le pruning, certaines fonctionnalités deprecated vont être supprimées. On salue le choix de SpringSource d’alléger son framework et de tout faire pour ne pas traîner du code legacy sur plusieurs générations (contrairement à d’autres).

Spring 3.0 nécessite a minima un JDK 5. Un sondage à été réalisé lors de la présentation et seule une personne de l’assemblée déclarait toujours utiliser le JDK 1.4. Le timing semble plutôt bon, le JDK 5 de Sun étant déjà passé au statut end of life récemment.

Un Expression Langage intégré à Spring core, plus costaud qu’il en a l’air …

L’une des grandes nouveautés de Spring 3.0 concerne la gestion d’un langage d’expression dans la déclaration des beans. Cette fonctionnalité est rendue possible par la modification du cœur de Spring. Si son utilisation reste pour le moment un peu timide, c’est l’une des briques nécessaires à certaines évolutions de modules annexes (Web). Il est vrai que nous ne sommes pas habitués à utiliser un tel mécanisme, le besoin peut même vous sembler limité, et pourtant … C’est également ce que je m’étais dit lors de la présentation de Juergen il y a un an . Depuis, chez mon client, je me suis surpris à constater à plusieurs reprises que cette solution m’aurait été utile.

L’utilisation des EL++ dans la déclaration de vos beans (XML ou annotations) vous permet d’une part de simplifier votre configuration et d’éviter de dupliquer certaines constantes dans vos fichiers de configurations. Cela dit, ce qui est décrit comme constante peut à ce jour déjà être centralisé par l’intermédiaire de variables gérées par le PropertyPlaceholderConfigurer et remplacées à l’initialisation du contexte. L’utilisation des EL++ vous permet ce même résultat directement au runtime ! Différentes classes scopées ‘prototype’ peuvent donc être instanciées avec des paramètres différents.

La fonctionnalité vous permet d’accéder out-of-the-box à différents contextes : systemProperties, systemEnvironment, request, session ou à toute propriété de beans déclarés dans Spring. Notez qu’il est possible d’enrichir ceux-ci et d’y exposer vos propres contextes. Un mécanisme de SPI vous permet d’enrichir cette fonctionnalité et vous permet d’exposer vos propres contextes. A quoi cela sert il ? Il est par exemple possible, moyennant un peu de code, d’accéder via EL à une valeur stockée en base de données.

Le support REST, une surcouche à Spring MVC

Le support REST a été développé par Arjen, dans la mesure où il est également le fondateur de Spring WS. Nous aurions d’ailleurs pu penser qu’il se serait basé sur le fonctionnement de Spring WS pour réaliser cette fonctionnalité. Arjen m’a d’ailleurs dit avoir imaginé une telle solution avant de rebrousser chemin : le support de REST se rapproche beaucoup plus de Spring MVC que de Spring WS.

Le support REST de Spring 3.0 ne repose sur aucune implémentation existante. Ce n’est donc ni du RESTlet, ni du JAX-RS, c’est du 100% SpringSource et l’une des fonctionnalités proposées par Spring MVC.

Côté client, le nouveau RestTemplate vous permet d’accéder très facilement à n’importe quel service REST.

Les meta-annotations, c’est bien mais pas universel

Arjen a présenté le mécanisme de méta-annotation proposé dans Spring 3.0. Il s’agit d’offrir la possibilité de regrouper plusieurs annotations en une seule. Il est ainsi possible de regrouper certaines caractéristiques par type de composant. Voici l’exemple d’une annotation @MyKindOfComponent, qu’il est possible d’utiliser sur n’importe quelle classe. Celle ci possédera ainsi toutes les caractéristiques des différentes annotations.

@Service
@Scope("request")
@Transactionnal
@Retention(RetentionPolicy.RUNTIME)
Public @interface MyKindOfComponent {
  ...
}

Au delà de la tentative d’apaisement des anti-annotations, ce mécanisme peut vous permettre de tagger certains types de classes selon vos besoins. Vous pourrez ainsi facilement retrouver ces classes via un aspect posé sur votre annotation personnalisée.

Spring 3.1 sera pleinement compatible Java EE 6

L’annonce a été faite lors des conférences par Arjen, et modéré ensuite par Alexis Moussine-Pouchkine lors de sa présentation sur « Java EE vs Spring » qui espère que SpringSource implémentera a minima le profil Web des spécifications Java EE 6. Un subset de fonctionnalités sera choisi pour être intégré à Spring 3.1. Il s’agira des fonctionnalités qui ont un intérêt direct pour Spring. Il serait un peu farfelu de penser que Spring implémentera Java EE 6 dans son intégralité. La liste de ces fonctionnalités n’est d’ailleurs à ce jour pas fixée définitivement. Certaines comme JPA 2.0 et JSF 2.0 sont déjà compatibles et intégrées à Spring 3.0. Les autres attendront la prochaine release.

Cela mis à part, Arjen se dit intéressé par certaines fonctionnalités de Java EE 6. Une configuration de Spring MVC simplifiée par l’utilisation des Web Fragments de Servlet 3.0 est envisagée. L’autre fonctionnalité que j’ai évoquée est l’exécution asynchrone d’handlers Spring MVC : Arjen s’est montré également intéressé même s’il m’a dit qu’il existait déjà des moyens d’avoir un mécanisme similaire (j’ai cherché, mais pas trouvé…).

Pour finir, deux sujets un peu moins ‘Spring 3.0′ …
Ayant effectué quelques applications Android, j’aurais aimé avoir une solution me permettant d’accéder le plus simplement possible à des services REST / MVC … Du coup, je lui ai demandé si, en interne, ils étaient intéressés par cette petite communauté de développeurs, et s’ils avaient des idées pour faciliter la création d’applications Android. Evidemment, je n’attendais pas beaucoup de cette question ; la réponse a ressemblé à cela : un restTemplate côté Android ou une version light de Spring remoting est une bonne idée … qu’il faudra creuser … par vous-même

Enfin, l’interview s’est terminée par une question personnelle. Quel est, selon lui, le sujet le plus hype du moment : les langages de scripting sur JVM à la Groovy, les nouvelles techniques de concurrence avec les acteurs Scala, la modularisation et le rechargement d’applications, ou le Cloud Computing … C’est ce dernier qui a sa préférence.

Merci à Arjen pour sa présentation et pour le temps consacré à l’interview.
Au plaisir de renouveler cela l’année prochaine.

Une reconnaissance méritée
C’est une très belle opportunité pour Jetty qui était jusqu’à présent beaucoup plus embarqué que Tomcat par des grands projets de Cloud Computing (Google App Engine, Hadoop, Gigaspace XAP, etc) mais n’avait pas constitué sa propre offre.

Sur les pas d’Amazon ?
Le mariage d’Intalio avec Webtide est assez différent de celui de SpringSource avec VMWare et Cloud Foundry. Alors que la deuxième union concerne des spécialistes de l’infrastructure, Intalio est lui issu de l’univers des applications CRM et s’étend vers les infrastructures de Cloud Computing comme l’a fait Amazon auparavant.

Des serveurs J2EE lourds absents
Nous remarquerons à l’occasion que les serveurs J2EE heavyweight se font très discrets dans cette période d’avalanche d’annonces sur Java Platform as a Service, on peut s’attendre à ce qu’ils répondent sur cette tendance qui va bouleverser les modes de fonctionnement dans les data centers et menacer leurs parts de marché.

Ils en parlent

• L’annonce officielle par Intalio
• L’annonce par Greg Wilkins, co-fondateur de Webtide
• InfoQ : Intalio acquires Webtide

Actualité éditeurs / SSII

• SpringSource lance CloudFoundry

SOA

• David Chappell et Ted Neward : SOA est un échec … mais aussi un progrès

Le coin de la technique

• Acquisition d’Ehcache par Terracotta, nécessaire et suffisant ?
• ChromeDevTools
• Pas de Swing Application Framework dans le JDK 7

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

• Hadoop World 2009
• Sortie le 30 septembre de Google Wave Preview

Actualité éditeurs / SSII

SpringSource lance CloudFoundry

Rod Johnson l’annonçait jeudi dernier sur son blog, l’éditeur fait ses premiers pas dans le monde du cloud computing. Il s’agit en effet d’une interface web qui ne manque pas de rappeller Google App Engine permettant d’installer des applications Java sur le nuage. Dans cette première version, on nous propose de déployer des applications hébergées sur le fameux Spring Tc Server, avec out of the box, la supervision Hyperic, la possibilité d’utiliser une base de données MySQL, et évidemment le support de Grail, si cher à Rod.

Au menu, bien évidemment le support et la répartition automatique de la montée en charge. Pour le moment, le tout est déployé sur Amazon EC2, mais Rod espère bien le voir déployé prochainement sur vSphere (la solution de cloud computing de VMWare). Nous souhaitons longue vie à ce nouveau produit de SpringSource qui confirme une fois encore sa montée en puissance. Notez, tout de même pour information que c’est Chris Richardson et son équipe qui s’est chargé de la réalisation de CloudFoundry.

L’article de Cyrille Le Clerc sur SpringSource et Java Platform As A Service vous permettra d’y voir un peu plus clair sur la stratégie poursuivie par SpringSource.

SOA

David Chappell et Ted Neward : SOA est un échec … mais aussi un progrès

David Chappell a retrouvé une discussion qu’il a eu avec Ted Neward en 2008 sur SOA.

Au-delà de l’évocation des liens entre Service Oriented Architecture (SOA), Software as a Service (SaaS) et Cloud computing, nous retiendrons de cet échange : SOA a échoué à tenir sa double promesse « Réutilisation et agilité ».
L’agilité est une forme de réutilisation puisqu’elle permet de créer de nouveaux services en assemblant facilement des services existant. La réutilisation des services métiers a échoué, et par effet de bord, l’agilité n’a pas été obtenue. La réutilisation des services métiers est analogue à la réutilisation des objets métiers à la fin des années 90.
La cause de cet échec, pour SOA comme pour les objets métier, n’est pas technique mais principalement humaine. Les organisations n’ont pas créé les conditions pour inciter les équipes à partager leur travail ni à réutiliser le travail des autres (Cf. « Le syndrome Not Invented Here » et « Propriété des composants et Financement au projet« ).

En revanche, la réutilisation des objets techniques a réussi, les frameworks .Net et Java EE en sont des exemples. De plus, l’orienté objet a convaincu comme paradigme de programmation. Pour SOA, la réutilisation de services techniques comme la gestion de l’identité ou la couche d’accès aux données basiques fonctionne.

Il s’agit donc d’un échec du SOA tel qu’on nous l’a promis mais en revanche d’un succès de l’approche par service.

Pour ce qui est des ESB, il s’agit principalement d’un coup marketing des éditeurs de solutions d’intégrations mais aussi d’une évolution des paradigmes d’intégration : l’intégration par services à succédé à l’intégration par base de données.

Alors SOA est un échec ? Oui si l’on regarde les promesses initiales qui n’ont pas été tenues ; non si l’on voit les transformations orientées service qu’elle apporte.

Le coin de la technique

Acquisition d’Ehcache par Terracotta, nécessaire et suffisant ?

Le teaser largement propagé via Twitter et les différents blogs des acteurs de Terracotta est tombé. Terracotta a fait l’acquisition d’un des frameworks open-source les plus populaires du marché : Ehcache. Drôle de teasing, sous la forme d’un hash md5, pour une drôle d’annonce. Ce mariage ressemble plus à un arrangement entre amis qu’a un véritable rachat :

• Ehcache et Terracotta fonctionnent conjointement depuis bien longtemps.
• Ehcache est porté par une seule personne : Greg Luck.
• La vente de support Ehcache ne fonctionne pas vraiment, dixit Greg Luck.
• Le code source de Ehcache est très léger, et sa partie la plus complexe, le cache distribué, concurrence avec une grande simplicité Terracotta.

Alors, pourquoi avoir racheté Ehcache ?

Selon certains analystes, après le rachat de SpringSource, VMWare a la volonté d’élargir son portefeuille d’outils et de middleware Java, et Terracotta serait pressenti. C’est en tout cas l’hypothèse mise en avant par quelques gaillards de Terracotta (encore une fois, merci Twitter). Notre sentiment, trop de bruit pour que cela soit d’actualité. Par contre, il nous semble clair que Terracotta désire se faire racheter. Et pour cela, plusieurs problèmes doivent être réglés :

• Malgré les différentes versions, Terracotta suscite des résistances, en cause son approche bas niveau (JVM / Bytecode) qui freine bon nombre d’utilisateurs. D’ailleurs, Terracotta ne fonctionne pas avec toutes les JVM.
• L’utilisation de ce framework n’est pas transparente, quoi qu’en disent les documentations. Il est facile de se tromper sur le choix des objets à partager et les poses de lock. Tout cela fait qu’à l’utilisation, la mise en place de celui-ci est tout sauf triviale.

Et c’est là qu’Ehcache intervient !

• Mis en lumière par le cache L2 d’hibernate, Ehcache fonctionne également avec d’autres produits star comme Spring, Alfresco et Liferay. Il est devenu l’une des apis de cache les plus utilisées par les développeurs. On parle de plusieurs centaines de milliers de projets utilisant celui-ci. Avec ce rachat, Terracotta espère se rapprocher davantage de cette communauté en s’appuyant sur la bonne image d’Ehcache pour rassurer les développeurs.
• D’autre part, Terracotta gonfle sa stack logiciel et propose dans son portefeuille un mécanisme de cache distribué alternatif plus haut niveau.

Au final, petite annonce ? Pas si sûr ! Terracotta signe ici un joli coup de communication et se met dans les meilleures conditions en vue d’un éventuel prochain rachat.

ChromeDevTools

Pour ceux qui ne sont pas à l’aise avec le débogage Javascript par l’interface de Firebug ou tout simplement ceux qui souhaitent débugger intégralement leur application dans Eclipse, y compris le Javascript client, voici un petit outil (développé par Google) qui vous le permettra : le Google Chrome Dev Tools (par l’Eclipse Zone).

Le projet se compose du Chrome Dev Tools SDK, API Java permettant à une application en mode debug de communiquer avec le navigateur Google Chrome (localhost en TCP/IP) , et de l’Eclipse Debugger, le plugin Eclipse qui vous permettra de débugger votre application.

Ce dernier propose entre autres :

• Breackpoints
• Watches
• Step in / over / into
• Évaluation d’une sélection de texte
• Évaluation sur mouse hover
• Exceptions reportées dans la vue Error Log

Côté mise en place, il vous faudra au minimum, comme vous pouvez vous en doutez, un navigateur Google Chrome en version 3.0.189.0 (actuellement en beta) et un Eclipse 3.4.2. L’installation du plugin se fera par l’Update Site avec cette URL.
Il vous faudra ensuite lancer votre Chrome avec le paramètre --remote-shell-port=9222 (ou le port de votre choix) et définir, dans le menu Debug Configurations d’Eclipse, une nouvelle Chromium Javascript configuration avec le port spécifié pour Chrome. Et à partir de là, à vous les breakpoints et le debug de votre application dans Eclipse !

Pas de Swing Application Framework dans le JDK 7

Il y a quelques mois nous vous parlions de la disponibilité d’une roadmap détaillée pour le JDK 7. Elle incluait entre autre la JSR-296 (Swing Application Framework), une spécification destinée à simplifier le développement d’applications Swing grâce à :

• Des annotations @Action pour déclarer les actions Swing plus facilement qu’en sous-classant AbstractAction puis en redéfinissant la méthode actionPerformed()
• Gestion de l’enregistrement de l’état des fenêtres à la fermeture de l’application
• Simplification de la gestion des ressources
• Gestion du cycle de vie de l’application

Les apports sont intéressants car répondent bien aux réalités des projets Swing courants, mais n’y répondent que partiellement. En effet il aurait été interessant de voir se créer une synergie avec la JSR-330 (Dependency Injection for Java) afin d’apporter l’injection de dépendance aux applications client lourds. De plus, ce framework ne simplifie pas la définition des interfaces en Swing, opération se révélant souvent assez laborieuse en raison d’APIs vieillissantes et probablement trop bas niveau.

Alexander Potochkin nous apprend maintenant que cette JSR ne sera pas prête dans les temps pour la roadmap prévue et qu’en conséquence son intégration au JDK 7 est annulée. Dans ces conditions, les apports du JDK 7 à Swing seront quasi nuls, ce qui constituera une réponse bien peu satisfaisante aux débats ayant animé cette communauté il y a quelques mois.

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

Hadoop World 2009

La société Cloudera, spécialisée dans le support aux utilisateurs de Hadoop, a annoncé la première conférence mondiale consacré à Hadoop : Hadoop World. Cette conférence se tiendra à New-York City en octobre de cette année. Elle est soutenue par des sponsors de taille comme IBM, Intel et Yahoo.

Le nombre de candidat à la prise de parole est tellement important que l’agenda n’est pas encore fixé. Le thème sera « Hadoop is everywhere », on aura donc droit à des sujets aussi bien sur des applications utilisant déjà Hadoop, que sur les implications coté administration de parc.

Les inscriptions sont ouvertes …

Sortie le 30 septembre de Google Wave Preview

Présenté il y a quelques mois comme une évolution majeure de notre façon de communiquer en ligne, Google Wave sera bientôt disponible au public. 100 000 utilisateurs sont attendus une fois le service ouvert.

A l’heure actuelle, les développeurs qui ont pu testés ont eu de gros problèmes de disponibilité de la plateforme. Sur InfoQ, on apprend que pour le 30 septembre, l’objectif du responsable technique de Wave API, Douwe Osinga, est bien sûr d’améliorer la stabilité du système mais aussi d’ajouter des fonctionnalités à l’API. Par conséquent, il ne leur restait que peu de temps pour stabiliser le bac à sable.

Dans les nouvelles fonctionnalités, l’accent a été mis sur l’API liée aux robots qui est à présent ouverte. Grâce aux robots, on peut répondre de manière applicative à des évènement sur la wave, ce qui permet d’interagir avec les autres participants, ou d’échanger des informations avec des systèmes extérieurs.

Si vous souhaitez être averti de l’ouverture du service, inscrivez-vous. Vous pouvez même écrire un message d’encouragement à l’équipe de Google Wave. Ils en auront certainement besoin pendant le moins prochain…

Rod Johnson annonce dans SpringSource Launches Enterprise Java Cloud que SpringSource offrira à ses clients non seulement la possibilité de déployer sur le cloud public Amazon EC2 mais aussi et surtout sur des clouds privés.

Il s’agira vraisemblablement de la mutualisation de nos plates-formes Java actuelles avec un chef d’orchestre Hyperic et des serveurs tc Server (Tomcat augmenté de fonctionnalités d’administration) ; la JVM sera Sun HotSpot et l’OS de prédilection sera RehHat Enterprise Linux (RHEL) même si Windows, Solaris et MacOSX seront proposés (détails ici).

Il ne nous faudra que quelques minutes pour déployer de nouvelles applications web ou pour ajuster les ressources CPU et mémoire allouée à une application par l’ajout ou la suppression de nœuds dans un cluster.

Techniquement, il n’y a pas de rupture par rapport à ce qu’offrent depuis longtemps les serveurs JEE « lourds » (IBM WebSphere, Oracle/BEA Weblogic, RedHat JBoss App Server ou Sun Glassfish).

Cependant, les mentalités ont changé, les esprits sont marqués par la simplicité d’exploitation des Public Clouds. Les équipes d’exploitation sont en train de se transformer, les processus s’allègent et l’offre lightweight de SpringSource tombe à point nommé.

Et la virtualisation matérielle dans tout ça ? Rod Johnson nous dit que la Tomcat Platform As A Service s’exécutera « aussi sur vSphere », le produit phare de son récent acquéreur VMWare. La nuance est forte entre « aussi sur » et « principalement sur ».
Nous le verrons à l’usage, le duo RHEL / Sun JVM sera la couche d’abstraction suffisante pour exécuter la plupart de nos applications Java. Le renfort de la virtualisation matérielle ne se justifiera que dans un nombre limité de cas comme les serveurs J2EE s’avèrent rarement nécessaire face aux simples Tomcat, Jetty ou Glassfish V3 …

Actualité éditeurs / SSII

• VMWare – SpringSource, pourquoi ?
• Les acteurs du marché du Complex Event Processing

Le coin de la technique

• iBatis suit les dernières tendances Java
• Apache HTTP Client 4.0 finalisé
• Tour d’horizon de CouchDB

Actualité éditeurs / SSII

VMWare – SpringSource, pourquoi ?

Pourquoi VMWare a racheté SpringSource dont le métier et la culture sont si différents ? Pourquoi un tel prix ?

Cyrille Le Clerc (Xebia) propose son analyse du rachat de SpringSource par VMWare : « Pourquoi VMWare / SpringSource ? Virtualisation matérielle vs. Cloud« .

Les acteurs du marché du Complex Event Processing

Paul Vincent, Tibco, a diffusé un récapitulatif des différents acteurs du marché du Complex Event Processing listant l’ensemble des éditeurs proposant des solutions classés par date d’arrivée sur ce marché.
Il y fait bien la distinction entre les produits se basant sur un système de requêtes temps réelles et ceux basés sur un système de règles.

Il est ainsi possible de visualiser l’arrivée successive des nombreux acteurs sur ce marché en pleine croissance. Par ailleurs on remarque qu’Esper est le seul moteur de requêtes CEP Open Source du marché tandis que Drools, grâce à sa récente version 5 est devenu l’unique moteur de règles CEP qui soit Open Source. Ces nouveaux entrants viennent ainsi perturber StreamBase, Coral8 et Progress sur leurs positions investies il y a plusieurs années.

Le coin de la technique

iBatis suit les dernières tendances Java

iBatis est un framework Apache souvent positionné face aux solutions ORM telles qu’Hibernate. En effet il adopte une stratégie différente puisqu’il ne cherche pas à créer un modèle objet au dessus du modèle relationnel, mais plutôt à faire un mapping objet des données d’entrée et de sortie des requêtes SQL. Traditionnellement ce mapping se décrivait par un lot de fichiers XML de configuration.

Début 2007, l’équipe des développeurs d’iBatis a créé une page Wiki pour recueillir les propositions pour une version 3.0 qui profiterait des nouveautés de Java 5 pour améliorer l’ergonomie de leur framework.

Après de longs débats, et développements, une série de 2 versions bêta a été diffusé. Une première version de documentation est également disponible, permettant de faire le tour des nouveautés les plus intéressantes :

• Ajout d’un SelectBuilder permettant de construire dynamiquement des requêtes SQL, remplissant ainsi un rôle similaire aux Criterias d’Hibernate. Ce builder offre aux développeurs un DSL interne très élégant basé sur une clause import static Java.
• Configuration du mapping par annotations. On dispose ainsi d’annotations @Insert, @Update, @Delete, @Select et @Result à placer sur les Pojos. L’équipe iBatis reconnaît par contre la possible lourdeur de ce modèle de configuration lorsque des mapping très complexes doivent être définis.
• Possibilité de créer des DAOs utilisant des generics en type de retour. Typiquement une méthode listAllEmployees() retournera un type List<Employee> et non plus un type List.

iBatis répond à un besoin réel, car il propose une solution de persistance dont le niveau d’abstraction est intermédiaire entre JDBC et JPA. On ne peut donc que se réjouir de ce rafraichissement de l’API, l’alignant ainsi sur les tendances du moment dans le monde Java que sont les annotations, les DSLs, et autres interfaces simplifiés, qui permettent d’améliorer la productivité du développement.

Apache HTTP Client 4.0 finalisé

La refonte du client HTTP d’Apache a été initiée il y a deux ans avec l’arrivée d’une première version alpha. Un an après arrivait une première version bêta. Apache annonce maintenant la disponibilité d’une version finalisée du projet.

Au fil des années un nombre croissant de projets se sont basés sur HTTP Client lui concédant ainsi une certaine omniprésence. Son intérêt par rapport au client HTTP standard de Java est d’offrir une plus grande richesse de fonctionnalités liées à une meilleure flexibilité d’utilisation.

Cette nouvelle version majeure est une réécriture totale du projet, expliquant donc son temps de gestation particulièrement long. L’architecture y est repensée pour offrir une meilleure modularité et des possibilités d’extensions supplémentaires. Le client est ainsi désormais constitué de deux modules :

• HttpCore apporte les fonctionnalités fondamentales du protocole HTTP et offre le choix entre un modèle d’I/O bloquant ou non bloquant en s’appuyant sur NIO.
• HttpClient se base sur HttpCore pour offrir des fonctionnalités supplémentaires de HTTP telles que la gestion des cookies et l’authentification.

Une documentation très complète est déjà disponible pour HttpCore comme pour HttpClient.

Tour d’horizon de CouchDB

Une présentation de CouchDB par Jan Lehnardt, développeur sur le projet, lors du QCon de novembre 2008 vient d’être mise à disposition. Elle offre un aperçu global de CouchDB qui permettra de saisir l’ensemble de ses intérêts. Ainsi les principales caractéristiques de cette base de données mises en avant sont :

• Base de données orientée documents : les informations sont groupées par documents qui sont stockés de manière versionnée.
• Optimistic locking : CouchDB se base sur un numéro de version stocké au sein du document.
• API Restful : les fonctions d’ajout, lecture, modification et suppression (CRUD) sont accessibles par une API Resful permettant ainsi une intégration triviale avec n’importe quel langage et plate-forme.
• Views : CouchDB n’offre pas de mécanisme de requête tel qu’on en trouve habituellement sur les bases de données relationnelles. Ici tout n’est que vue des documents générée dynamiquement par MapReduce.
• Réplication et résistance aux crashs : CouchDB supporte un mécanisme de réplication peer to peer lui permettant d’offrir une haute disponibilité des données sans effort supplémentaire.

Jan Lehnardt rappelle en outre que CouchDB est distribué sous licence Apache et que le projet est soutenu par IBM. Les lecteurs intéressés par CouchDB pourront également se tourner vers la documentation du projet ou encore vers le livre qui lui est consacré chez O’Reilly, prévu pour novembre, et d’ores et déjà librement accessible en ligne.

Mon analyse est que VMWare a racheté SpringSource parce que le cloud computing de forme Platform As A Service (PaaS) à la Google App Engine va bientôt mieux répondre que la virtualisation matérielle aux besoins d’optimisation des data centers Java. Selon l’adage « Si quelqu’un scie la branche sur laquelle je suis assis, mieux vaut que ce soit moi », VMWare s’est dotée de l’expertise de SpringSource sur Tomcat et Hyperic.
Je parlerai des applications Java légères (Servlets, JDBC, JPA et JMS) qui sont aujourd’hui largement majoritaires dans nos data centers Java. Billy Newport, IBM WebSphere, reconnait qu’elles représentent 80% des cas, SpringSource aurait sûrement des chiffres plus élevés.

• Optimiser la CPU des data centers
• Les atouts de la virtualisation matérielle
• Les limitations de la virtualisation matérielle pour Java
• Mutualisation en Java : De simples serveurs Linux-Tomcat suffisent
• Adaptation CPU et RAM en Java : Le modèle ‘scale out’
• Virtualisation matériel : Un marché plus concurrentiel et moins lucratif
• One size does not fit all : Concilier virtualisation matérielle et cloud pour optimiser l’utilisation des data centers

Optimiser la CPU des data centers

Les data centers débordent, l’électricité manque, les climatisations saturent, les planchers s’effondrent, les racks sont pleins et pourtant, les serveurs ne font rien, les CPU ne sont utilisées qu’à quelques pourcents !
La virtualisation matérielle, dont VMWare est un des leaders, propose d’adresser ce problème en introduisant une couche d’abstraction appelée hyperviseur entre le matériel et le système d’exploitation : plusieurs instances de système d’exploitation s’exécutent ainsi sur la même machine.
Considérons 10 serveurs qui consomment chacun en moyenne 5% de CPU, la virtualisation matérielle permet de les regrouper sur une seule machine physique qui atteindrait alors un taux d’utilisation de l’ordre de 50%. Malgré la chute du prix de la RAM, la mémoire vive de ce serveur mutualisé risque fort d’être insuffisante, l’hyperviseur règlera ce problème en recourant à la pagination de la mémoire (swap) comme un système d’exploitation le fait déjà à son niveau.
Et si par malheur ces serveurs venaient à être sollicités en même temps et à saturer la machine qui les héberge, les solutions de virtualisation parviennent maintenant à déplacer certaines instances sur d’autres serveurs physiques de façon transparente, sans même arrêter le service.

Les atouts de la virtualisation matérielle

Un atout essentiel de la virtualisation est le très faible coût d’adaptation des applications existantes puisqu’elles continuent à s’exécuter sur le même système d’exploitation avec le même voisinage. La virtualisation matérielle est transparente pour les applications, elle n’exige pas de changement de version du système d’exploitation, des librairies utilisées, des répertoires de travail ou des ports d’écoute.
Si une application est tellement exigeante qu’elle requiert une version de système d’exploitation dépassée ou qu’elle a été compilée avec la version très ancienne d’un driver de base de données, ce n’est pas grave. La virtualisation matérielle maintiendra cette application revêche isolée dans sa bulle et elle sera mutualisée comme les autres.
Un autre atout de la virtualisation est l’adaptation de la CPU et de la RAM allouée à chaque application selon ses besoins. De la même façon qu’un système d’exploitation sait allouer du temps CPU et de la RAM à une application qui a un pic d’utilisation, l’hyperviseur sait privilégier une instance parmi toutes celles qu’il exécute simultanément. Considérons 20 applications qui s’exécutent chacune sur un serveur bi-processeurs, la virtualisation matérielle permet de les regrouper sur un seul serveur quadri-processeurs et en cas de pic, allouer quatre processeurs à une seule application, le double de ce qu’offrait la solution non virtualisée.

Les limitations de la virtualisation matérielle pour Java

La première limitation de Java à la virtualisation matérielle est la gestion de la mémoire par les machines virtuelles. Les JVM assument que toute la mémoire qu’on leur alloue est en RAM, elles accèdent indifféremment à tout cet espace mémoire et le parcourent intégralement très souvent pour les garbage collections. De ce fait, la performance des applications Java s’effondre dès que leur mémoire est paginée. Pire encore, certains composants comme les timers des caches ou des gestionnaires de transactions échouent lorsque les temps de réponse sont anormalement longs et les applications tombent alors en erreur.
Ce problème est d’autant plus crucial pour la virtualisation matérielle que, du fait des techniques de garbage collection, les JVM libèrent peu de mémoire quand les applications sont moins utilisées.
Par ailleurs, l’adaptation à l’exécution de la CPU et de la RAM allouée à chaque application selon ses besoins est inadaptée en Java.
Le premier point bloquant est que l’espace mémoire utilisé par une JVM est défini au démarrage (Xmx) et ne peut changer lors de l’exécution. Ensuite, augmenter la puissance de traitement d’une application web Java nécessite non seulement d’allouer de la CPU et de la RAM, mais aussi de redimensionner les pools de threads http ou de connexions à la base de données ainsi que la taille de nombreux caches applicatifs (sessions http, objet venant de la base, etc).
Il faudrait donc que l’hyperviseur change les configurations Java, cela nécessite aujourd’hui d’interrompre le service pour redémarrer les applications. La promesse de transparence de la virtualisation matérielle devient caduque, le palliatif est d’avoir des middlewares qui interagissent avec la virtualisation matérielle.

Mutualisation en Java : De simples serveurs Linux-Tomcat suffisent

Si certaines applications sont revêches à la mutualisation, Java fait plutôt preuve de très bon voisinage.
Une application Java est quasiment agnostique du système d’exploitation et des libraires qui l’entourent, il lui suffit d’un répertoire pour ‘dezipper’ une JVM (<20 Mo), un moteur d'exécution (Tomcat < 5 Mo) et l'application.
Cette facilité d'installation est utilisée au quotidien. Nous développons sous Windows, MacOS ou Ubuntu pour déployer sur RHEL, AIX ou Solaris. Beaucoup d'équipes qui déploient en production sur un 'gros serveur' J2EE poussent même souvent plus loin cette portabilité en préférant utiliser pour le développement un serveur léger : Tomcat ou Jetty.
Pour ce qui est des problèmes de voisinage liés au port d'écoute ou aux répertoires utilisés, le monde Java, particulièrement sous Tomcat, a déjà banalisé ce partage en démarrant une instance de serveur par application web. De ce fait, il est fréquent de voir sur de simples serveurs bi-processeurs plus de quatre instances Tomcat démarrées.
Grâce à la faible adhérence d'une application Java à son environnement d'exécution et à l'habitude d'installer plusieurs serveurs « à la Tomcat », le niveau naturel de mutualisation des ressources CPU et RAM pour des applications Java est au dessus du système d’exploitation. La complexité et les coûts de la virtualisation matérielle sont très rarement justifiés avec Java. Une simple batterie de serveur Linux avec des serveurs Java ‘légers’ comme Tomcat, Jetty ou Glassfish V3 répond au besoin d’optimisation des data centers Java en conciliant simplicité et faible coût.

Adaptation CPU et RAM en Java : Le modèle ‘scale out’

A la différence du modèle ‘scale-up’ de la virtualisation matérielle qui augmente la CPU et la RAM d’une instance pour tenir la charge, Java utilise un modèle ‘scale-out’ qui consiste à augmenter le nombre d’instances de l’application. Pour garantir la haute disponibilité ou la tenue à la charge, nous déployons des clusters de 2, plutôt 3, voire plus, instances de nos applications Java.
Déployer un nouveau nœud se fait aujourd’hui en moins d’une heure pour une équipe entrainée et ce délai va sensiblement diminuer. La roadmap de SpringSource Tc Server permettra d’adapter les ressources CPU et RAM d’une application Java en moins de 5 minutes d’ici deux ans au plus par simple démarrage ou arrêt de nœuds d’un cluster.
Les tâches à accomplir sont limitées pour SpringSource, IBM le propose depuis des années sur son sophistiqués mais complexe WebSphere eXtended Deployment et Gigaspace vient de l’introduire sur sa grille XAP sur un socle Jetty, SpringSource doit principalement ajouter un mécanisme de déploiement de Tomcat à l’agent Hyperic/AMS et améliorer le scripting de la gestion de configuration Tomcat du serveur d’administration Hyperic/AMS.

Virtualisation matériel : Un marché plus concurrentiel et moins lucratif

En plus d’être remise en cause par la rupture technologique du cloud computing, la virtualisation matérielle est aujourd’hui confrontée à une baisse des marges. VMWare a connu des années très lucratives pendant lesquelles elle a été pionnière ‘pure player’. Certains disaient que « VMWare a porté sur architecture x86 la virtualisation des mainframes ».
Le marché de la virtualisation est aujourd’hui mature, les grands acteurs des systèmes d’exploitation se jettent dans la bataille et la concurrence s’annonce rude pour VMWare.
L’univers Windows est condamné à rétrécir mécaniquement pour VMWare avec l’arrivée en force de Microsoft. Les perspectives sont toutes aussi dures dans le monde Linux avec la montée en puissance des offres de RedHat ou de Sun. Nous avons vu par le passé que toutes les fonctionnalités clefs des gros Unix sont arrivées dans Linux ; les zones Solaris et les partitions AIX sont aujourd’hui banalisées, il n’y a pas de raison que ces technologies n’arrivent pas dans le système d’exploitation au pingouin.

One size does not fit all : Concilier virtualisation matérielle et cloud pour optimiser l’utilisation des data centers

A l’époque où les applications n’étaient pas friendly à la mutualisation, la virtualisation était la technologie de prédilection pour optimiser l’utilisation des ressources des data centers. Aujourd’hui, les applications java légères déployées sous forme de cloud Platform As A Service sont très friendly à la mutualisation et se passent de la virtualisation matérielle. VMWare a suivi cette redistribution des cartes en achetant la solution de cloud computing Hyperic-TcServer-Tomcat de SpringSource.
La virtualisation matérielle risque de ne pas être utilisée sur les applications légères (Java, .Net, PHP, etc) qui représentent aujourd’hui la tendance dominante mais garde sa position de leader pour optimiser l’utilisation des ressources CPU et RAM des autres types d’applications.

Ressources

• « SpringSource: Chapter Two » : L’annonce du rachat par Rod Johnson, fondateur de SpringSource.
• « VMWare to acquire SpringSource » : L’annonce par Steve Herrod, CTO de VMWare.
• « Why Java is important to VMware but may not matter long term » par Billy Newport, IBM WebSphere.
• « SpringSource racheté par VMware » par Le Touilleur Express.

SOA

• Fuji, le futur d’OpenESB

Le coin de la technique

• Concevoir des APIs efficaces
• JavaFX : informations et controverses
• Sortie de Wicket 1.3.6
• @Inject standardisation de l’injection de dépendances
• Sortie de Tapestry 5.1
• Trucs et astuces Json – Restfull

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

• Soirée Datagrid au Paris Jug

SOA

Fuji, le futur d’OpenESB

La prochaine version d’OpenESB, qui sera estampillée ‘v3′, est en cours de développement sous le nom de code ‘Project Fuji’. Ce projet a été récemment mis en avant par Andi Egloff, dans un webcast qui fait le tour des nombreuses nouveautés. Les principales d’entre elles sont :

• Integration Flow Language (IFL) : il s’agit d’un DSL externe permettant de définir des flux d’intégrations. Le rôle de ce langage est donc le même que le DSL interne offert par Apache Camel.
• Distributed JBI : La spécification JBI (JSR-208) ne couvre pas la problématique de distribution des composants JBI sur plusieurs noeuds. Fuji apporte une extension propriétaire pour permettre cette distribution.
• Utilisation de composants OpenJBI : ces composants seront utilisables directement dans OpenESB v3. Le projet prévoit de mettre les composants dont la compatibilité aura été validée dans le repository Maven du projet.
• Enterprise Integration Patterns : un certain nombre d’EIP sera supporté en standard et configurable via le langage IFL.

La version finale d’OpenESB v3 est prévue pour le second semestre 2009, l’équipe du projet annonce une probable preview pour JavaOne en juin.

Le coin de la technique

Concevoir des APIs efficaces

John De Goes vient de publier une série de deux articles (première partie et deuxième partie) portant sur les bonnes pratiques de conception d’APIs. Il s’appuie sur un exemple d’API de configuration pour illustrer son propos. Les points qu’il met particulièrement en avant sont :

• Il est important de sélectionner le niveau d’abstraction approprié et d’assurer l’uniformité de celui-ci sur l’ensemble de l’API, ainsi que de définir et respecter une responsabilité pour chaque classe. Ceci concerne la granularité des méthodes, le type d’objets manipulés en entrée et en sortie, ainsi que la présence et le type d’exception éventuellement renvoyée.
• N’offrir qu’une seule possibilité pour chaque besoin, afin d’éviter la confusion chez l’utilisateur de cette API.
• S’appuyer sur les possibilités offertes par le langage pour empêcher certaines mauvaises utilisations d’une API.
• L’API doit être la plus intuitive possible afin de minimiser autant que possible le besoin pour l’utilisateur d’avoir à se plonger dans une documentation.

Certaines de ces idées sont déjà partagées par de nombreux développeurs, mais comme c’est souvent le cas dans l’énonciation de bonnes pratiques ou de patterns, tout l’intérêt réside ici dans la formalisation apportée par l’auteur.

Les lecteurs intéressés par cette problématique pourront se tourner vers le livre de Jaroslav Tulach, Practical API Design, qui apporte l’intéressant retour d’expérience d’un architecte de NetBeans, ou encore How to Design a Good API and Why it Matters par Joshua Bloch (auteur de Effective Java).

JavaFX : informations et controverses

Depuis plusieurs mois, nous vous rapportons les différentes informations et controverses à propos de JavaFX. Cette technologie RIA, développée par Sun, et introduite en décembre 2008 fait beaucoup parler d’elle car personne ne sait dire aujourd’hui ce qu’il adviendra de JavaFX dans les mois et années à venir.

Les propos particulièrement négatifs dont JavaFX a été victime à ses débuts se font moins nombreux, non pas parce que cette technologie a convaincu, mais parce qu’elle n’est plus au centre des débats. En fait, ceci est bénéfique puisque cela permet d’observer plus sereinement les différents exemples postés régulièrement par la communauté JavaFX naissante. Il ressort de ce tour d’horizon que les capacités actuelles de JavaFX ne prêtent pas à critique : les fonctionnalités de graphisme et d’animations qui sont offertes semblent satisfaire de nombreux développeurs. Le problème porte principalement sur les manques et les promesses non tenues à ce jour :

• la portabilité de JavaFX sur plusieurs environnements (_desktop_, web, mobile, et TV, le fameux ‘All the screens of your life‘) n’est pas assuré puisque le déploiement est impossible sur mobile, faute de device compatible. Le fonctionnement sur téléviseur est lui toujours prévu dans une version ultérieure.
• les composants graphiques de haut niveau sont absents. Il s’agit pourtant d’un élément indispensable pour le développement d’applications RIA.

Joshua Marinacci, un des meneurs de JavaFX chez Sun, a été interviewé par Scott Hanselman dans un podcast. Il annonce que la démonstration de JavaFX sur TV pourrait être faite lors de JavaOne 2009, en juin. Il reconnaît par ailleurs le marketing excessif entourant cette technologie.

Outre ces réflexions d’ordre technique, le rachat de Sun par Oracle constitue une autre source de débats. Personne ne sait quelle décision Oracle prendra quant à JavaFX : soutenir ce projet qui nécessite encore un investissement lourd pour prétendre réellement concurrencer les autres acteurs RIA ou abandonner ce marché. Les différentes opinions sur ce sujet sont présentées et argumentées dans le dernier podcast des Cast Codeurs.

Sortie de Wicket 1.3.6

Wicket, le framework orienté composant de la Fondation Apache, sort en version 1.3.6 (1.4 toujours en release candidate 2).

Malgré les 7 mois d’écart avec la version précédente, il ne faut pas s’attendre à une révolution pour cette nouvelle mouture. Il s’agit en effet d’une version de stabilisation et d’amélioration. On notera donc de nombreux correctifs de bugs et plusieurs améliorations.

Cette version est téléchargeable sur le site d’Apache ou en changeant votre version de pom.xml en 1.3.6.

A noter, toujours autour de Wicket, le retour critique de Tom’s Quest sur Wicket et ses limites après la présentation, chez Zenika, de Martin Dashorst, un des committers principaux de Wicket et coauteur du livre Wicket In Action.

@Inject standardisation de l’injection de dépendances

Pas mal de bruit la semaine dernière dans la blogosphère Java avec l’annonce par Google et SpringSource d’une nouvelle proposition de JSR dédiée à l’injection de dépendances : @Inject (« Annotations for Dependency Injection »).
Comme le souligne ‘Crazy’ Bob Lee, l’auteur principal de Google Guice, la sortie de Spring 1.0, il y a déjà 5 ans, a apporté l’injection de dépendances aux masses, via un fichier de configuration propriétaire. Il y a 3 ans, Google Guice a proposé la même chose via des annotations (et SpringSource propose la même chose depuis Spring 2.5).
Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).
@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Lire notre article à ce sujet : @Inject standardisation de l’injection de dépendances.

Sortie de Tapestry 5.1

Tapestry, dont on parlait récemment dans l’article l’injection de dépendances avec Tapestry IoC, passe en version 5.1 en respectant à la lettre son nouveau planning d’une version tout les 4 à 6 mois.
Outre les améliorations de performance et les nombreux bugs corrigés, la mise à jour embarque des nouveautés sur le support JavaScript, à la traîne par rapport au prédécesseur Tapestry 4.
Le rafraîchissement de plusieurs zones d’une page en une seule requête Ajax est maintenant supporté. Tapestry embarque maintenant la console JavaScript Blackbird.
Du côté des améliorations sur les templates, le chargement et le rendu des pages ont été optimisés, ce qui rend T5 plus rapide que jamais.
Vous pourrez aussi apprécier l’amélioration substantielle de l’archetype quickstart qui offre désormais une jolie interface, avec un design css intégré.
L’intégration de Spring est maintenant à double sens : on peut injecter des services Tapestry dans un Bean Spring.
Pour la prochaine version, qui sortira sans doute à la rentrée 2009, l’accent sera mis sur l’intégration de Spring Web Flow, et la possibilité d’utiliser une application Tapestry en tant que Portlet.

• Release note
• Site Maven du projet

Trucs et astuces Json – Restfull

Edwin Khodabakchian, fondateur de Collaxa (aujourd’hui au coeur de la stratégie SOA d’Oracle), nous donne quelques bonnes pratiques pour écrire des services web REST en utilisant Json (un couple qui a le vent en poupe). Actuellement lancé dans l’écriture de Feedly, une extension Firefox qui agrège des tweets et des entrés Google Reader, Edwin fera régulièrement profiter ses lecteurs de son expérience. Sans entrer dans les détails de ces bonnes pratiques, nous retiendrons l’astucieux découpage en 7 phases d’implémentation :

• Definir un service ou une ressource simple : définir le modèle Json et les 4 opérations REST et le servlet qui les fournit.
• Ecrire un client : utiliser le service avec un javascript simple. Cette possibilité est offerte par de nombreux frameworks, dont JQuery.
• Ajouter une étape de validation : modifier le service pour valider les ressources Json et utiliser les codes retour HTTP.
• Complexifier les ressources : modifier la hiérarchie d’Url pour servir des ressources plus riches. Tester la pérennité des ressources simples (phase 2).
• Ajouter un cache : améliorer les performances et la scalabilité de votre système.
• Implémenter la sécurité : utiliser une authentification web.
• Publier des événements business : pour découpler les processus REST des processus back-end. Les ressources REST sont traitées, un évènement business est lancé, qui déclenche le ou les traitements back-end.
• Gérer un cycle de vie pour les ressources : coupler un état de la ressource avec la phase de validation et la phase de publication des évènements.

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

Soirée Datagrid au Paris Jug

Le DataGrid au Paris Jug, c’est demain.
Pensez à réserver si ce n’est déjà fait.

Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).

@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Pourquoi autant de bruit ?

Une autre JSR qui parle d’injection de dépendances a déjà passé le stade de la proposition, la JSR 299, ex-Web Beans, portée en particulier par Gavin King de Red Hat, auteur d’Hibernate. La JSR 299 va beaucoup plus loin (trop?) que l’injection de dépendances, sujet abordé dans de précédentes revues de presse.

La JSR 299 a déjà beaucoup fait parler d’elle, car elle a récemment été remaniée, afin d’être intégrée à temps à Java EE 6 (dont la spécification doit être terminée dans 3 mois). Vous pouvez lire les commentaires sur notre revue de presse du 26 Janvier dernier, dans laquelle nous nous étonnions de l’absence de SpringSource dans la JSR 299.

Quelques extraits de ces commentaires :

Emmanuel Bernard (JBoss) : « …SpringSource n’a jamais demandé à faire partie du groupe d’expertise… »
Emmanuel Bernard : « …JBoss a passé un temps énorme à construire JSR 299… »
Antonio Goncalves (Java EE 6 Expert Group) : « …la JSR 299 ne se transforme pas radicalement, je dirais plutôt qu’elle réduit sa voilure et se concentre sur son but initial : un contexte unifié entre les EJBs et JSF… »
Cyrille Le Clerc (Xebia) : « …une JSR qui se transforme radicalement, au point de changer de nom, pendant la phase de Public Review, après deux années et demie de travail intensif, cela me parait exceptionnel et peu rassurant… »

Bonne idée, mauvais timing ?

C’est dans ce contexte que Google et SpringSource décident de proposer @Inject. L’intention est légitime, et les deux acteurs sont sans aucun doute les plus expérimentés sur le sujet de l’injection de dépendances. Il semble en effet beaucoup plus aisé pour Guice, Spring ou autre framework d’implémenter une JSR de la taille de l’éventuelle JSR @Inject, alors qu’on les voit mal implémenter rapidement la JSR 299. Google et SpringSource suggèrent donc à la JSR 299 de ne plus spécifier l’injection de dépendances, et de réutiliser les annotations définies dans @Inject (extrait de la proposition : « JSR 299 is defining a dependency injection framework for Java EE, and might support these annotations.« ).

En revanche le timing nous semble vraiment mal choisi : cette spécification est proposée à quatre mois de la validation de Java EE 6 (Septembre 2009). Cela semblait déjà compliqué pour la JSR 299 (dont l’inclusion à Java EE 6 n’a toujours pas été votée), et @Inject ajoute très tard son grain de sel.
Même si Bob Lee pense pouvoir faire valider @Inject par le JCP en cinq mois, ou moins dans le cadre de Java EE 6, il est peu probable qu’@Inject fasse partie de Java EE 6 ; on n’a jamais vu de JSR consensuelle validée aussi rapidement, comment ferait une JSR polémique ? La JSR 299 fait quant à elle face à un planning de plus en plus serré. Le résultat des courses est sans appel : on « risque » donc de voir arriver une spécification Java EE 6 sans JSR d’injection de dépendances.

Hormis Gavin King (JSR 299 – JBoss) et Bob Lee (@Inject – Google) qui ont âprement débattu sur la blogosphère, les membres des expert groups de JSR 299 et Java EE 6 sont restés silencieux … comme Rod Johnson, co-inspirateur de @Inject (qui était sans doute bien occupé la semaine dernière).

Enfin, je vous suggère de prendre quelques minutes pour lire le « brouillon » de proposition de JSR @Inject. On y voit de nombreux noms connus et reconnus parmi les supporters de cette JSR (Joshua Bloch, Paul Hammant – ThoughtWorks & PicoContainer founder, Doug Lea, Tim Peierls, James Strachan, Hani Suleiman, Jason van Zyl – Maven Plexus, Thiago H de Paula Figueiredo – Tapestry IoC). @Inject ne propose que de standardiser les annotations, et ne décrit pas la manière dont les dépendances vont être résolues, ce sera à la charge du conteneur. Le périmètre fonctionnel de la proposition est donc très focalisé.

Sous vos yeux ébahis, une injection de dépendance sans Spring, sans Guice et sans JSR

Pour rappel, même si aucune JSR d’injection de dépendances n’est intégrée dans le futur à Java EE 6, vous avez le droit d’injecter vos dépendances vous même, sans Spring, sans Guice, par exemple avec un simple constructeur Java !

public class MyService {
	private MyDAO myDAO;
	public MyService(MyDAO myDAO) {
		this.myDAO = myDAO;
	}
}

Ce qui vous permettra d’y injecter bouchons ou mocks depuis vos tests unitaires.

Quelques liens sur le sujet

• l’annonce sur le blog de Bob Lee
• la réaction de Gavin King et les échanges avec Bob Lee dans les commentaires
• le projet @Inject sur Google Code
• Proposition de la JSR @Inject
• quelques (rares) commentaires intéressants sur TSS
• @Inject sur twitter

Actualité éditeurs / SSII

• JBoss veut son DataGrid
• SpringSource renforce (encore) le lien développement / production

Le coin de la technique

• Quelques nouveautés pour Apache Derby
• L’actualité d’Apache Directory Server
• La mémoire native en Java

Actualité éditeurs / SSII

JBoss veut son DataGrid

Le projet JBoss Infinispan a été initié il y a peu. Il vient de produire deux versions alpha successives. Il s’agit d’une réécriture majeure du projet JBoss Cache auquel il succède et qu’il est destiné à remplacer. Le but premier affiché par ce projet est de produire une solution de DataGrid, là où son prédécesseur n’offrait qu’une technologie de cache distribué. L’ambition est forte, puisqu’il s’agit de se positionner sur un marché dominé par les solutions commerciales que sont Oracle Coherence et IBM eXtreme Scale.

Une récente interview de Manik Surtani, project leader d’Infinispan et JBoss Cache, associée aux informations diffusées sur le site d’Infinispan, permet de mieux répondre aux différentes questions que l’introduction de ce nouveau projet peut soulever :

• Parmi les atouts prévisionnels d’Infinispan (après sa finalisation) face à Oracle Coherence, Manik Surtani met surtout en avant la nature Open Source, LGPL, de son projet. Il souligne toutefois la richesse d’Infinispan tant dans le domaine des performances (grâce à une implémentation efficace du MVCC locking) que des fonctionnalités (intégration simplifiée à Amazon EC2 et S3, compatibilité serveur Memcached).
• La création d’un nouveau projet et donc d’un nouveau nom plutôt que le maintien de JBoss Cache est justifiée pour l’équipe par la réécriture et les changements d’API. On peut aussi aisément imaginer que le nouveau positionnement ‘DataGrid’ ne coïncidait guère avec un nom de projet ‘Cache’…
• Infinispan pourra être utilisé en tant que cache Hibernate, ce qui est assez logique compte tenu de l’affiliation JBoss de ce dernier.

Face à des concurrents commerciaux bien installés sur ce marché, la tâche ne sera pas aisée pour JBoss, et le but affiché de proposer une solution équivalente à Coherence est très audacieux compte-tenu de la maturité acquise par ce produit. Ce scénario n’est pas sans rappeler le positionnement qu’avait JBoss AS lors de son arrivée sur le marché des serveurs d’application, mais l’absence de roadmap datée pour Infinispan tend à indiquer qu’il faudra probablement s’armer de patience pour savoir si l’histoire se répétera.

SpringSource renforce (encore) le lien développement / production

SpringSource a annoncé aujourd’hui le rachat de Hyperic, l’éditeur du célèbre outil de supervision du même nom.
Le partenariat SpringSource / Hyperic ne date pas d’hier (SpringSource redistribuait une version améliorée du serveur Hyperic dans son produit SpringSource Application Management Suite depuis 2007), mais cette acquisition confirme la direction affichée par SpringSource ces derniers mois : contrôler l’ensemble du cycle de vie d’une application Java, de sa conception à son exploitation.
En effet, un très grand nombre de projets Java s’appuient aujourd’hui sur le framework Spring (phase de développement). Un très grand nombre de ces développements tournent sur le serveur openSource Tomcat, dont SpringSource propose une distribution commerciale depuis peu (Spring tc Server). Et aujourd’hui, grâce à l’acquisition de Hyperic, SpringSource propose de réaliser l’exploitation de ces serveurs d’applications.

On peut d’ailleurs supposer qu’Hyperic devrait rapidement évoluer et proposer une version commerciale encore plus ‘orientée’ vers le framework Spring et le serveur Tomcat que ne l’était Spring AMS, avec une offre de support afférente.
Parmi les évolutions probables (car souvent évoquées par SpringSource comme des problèmes à résoudre pour les développeurs), nous devrions avoir :

• Gestion de la configuration au niveau Hyperic. Actuellement, Hyperic ne permet de réaliser que des opérations Stop/Start sur la ferme de serveurs. tcServer propose la gestion de la configuration du serveur. On peut donc imaginer un modèle de données qui permettrait de configurer ses tomcats directement depuis l’outil de monitoring.
• Déploiement phasé. Comme avec JBoss ON, il est souhaitable de voir apparaître un outil permettant de déployer progressivement sur les noeuds d’un cluster (probablement basé sur un outil de scripting).
• Virtualisation. Le déploiement sur des machines virtuelles types VM-Ware sera facilité.

Sur ces sujets, l’apport (et l’expérience) de Hyperic sera déterminant.

On peut s’amuser à retracer les différents rachats de Spring. En 2004, Hyperic est né d’un fork d’une partie des équipes de Covalent. En février 2008, SpringSource acquérait Covalent. Un peu plus d’un an après, SpringSource reconstitue l’entité de 2004 en acquérant Hyperic.

Javier Soltero, CEO d’Hyperic affirme qu’il s’agit là d’un mariage de raison, entre deux acteurs qui partagent la même vision de l’informatique et qui sont les meilleurs (et des standards de facto) dans leur domaine respectif (le développement Java pour SpringSource, et le management IT pour Hyperic). Il va d’ailleurs rejoindre le board de SpringSource en tant que directeur technique des outils de Management.

Parmi les effets collatéraux, on peut noter la (très probable) fin du projet (déjà mal en point) RHQ, partenariat entre RedHat et Hyperic, qui visait à créer une plate forme ‘manageable’ basée sur JBoss.
Toutefois, JBoss ayant racheté la base de code d’Hyperic avant qu’il ne devienne « public source », la fin du partenariat ne veut pas forcément dire fin de JBoss On dont le code à été très largement modifié par les équipes JBoss.

Le choix de monétisation des assets open source devrait commencer à effrayer les mastodontes de l’informatique (IBM, Oracle, Microsoft), qui avaient fait du contrôle total de la stack applicative (Java dans un cas, .Net dans l’autre) leur pré carré. C’est d’ailleurs la volonté de Rod Johnson (annoncée lors de SpringOne Europe) : devenir un ‘One Stop-By Shop’, comme peuvent l’être ces géants du monde informatique.

Le coin de la technique

Quelques nouveautés pour Apache Derby

Une nouvelle version du moteur de base de données Java de la fondation Apache vient d’être diffusée. Cette version apporte à Derby une dose d’évolutions intéressantes pouvant aider dans certains cas d’utilisation. François Orsini en présente la liste. On retiendra en particulier :

• In-memory backend : Cette fonctionnalité, particulièrement mise en avant dès la version 10.5 preview, permet de stocker une base de données en mémoire et ainsi de s’astreindre du stockage sur disque. Derby rejoint ainsi HSQLDB et H2 Database qui offraient déjà une telle possibilité, très utile dans le contexte des tests unitaires ou de certaines applications ne nécessitant pas de persistance durable.
• Roles SQL : Ils permettent de simplifier l’administration des privilèges attribués à une base de données. La documentation de Derby est d’ores et déjà à jour et permet de faire le tour des possibilités offertes.
• Generated columns : Il s’agit de colonnes dont les valeurs sont calculées à partir d’autres colonnes d’une même table. Il est également possible de déclarer un index sur une telle colonne afin d’améliorer les performances sur certains types de requêtes. Cette fonctionnalité est une version allégée des virtual columns introduites dans Oracle 11g.

L’actualité d’Apache Directory Server

Lors du dernier podcast des Cast Codeurs, Emmanuel Lécharny, committer français sur Apache Directory, a fait un tour d’horizon de ce projet. Pour rappel, Apache Directory est un projet de la fondation Apache qui produit un serveur LDAP en Java (Directory Server) et un outil de visualisation / édition de directory LDAP basé sur Eclipse (Directory Studio).

Du fait de son orientation Java, le positionnement de Directory Server sur le marché n’est pas évident, aussi les cas d’utilisation ont été longuement décrits ; on retiendra :

• Les tests unitaires, puisque le serveur LDAP peut ainsi être contrôlé et se faire injecter des données par Java lors du déroulement des tests.
• Embarquement du serveur LDAP dans l’application grâce au mode embedded de Directory Server, lorsque l’on ne souhaite pas dépendre d’un serveur externe.
• Profiter de la simplicité de configuration de Directory Server pour le mettre en place rapidement en premier lieu pour éventuellement passer ensuite à un serveur commercial.

Ainsi, lors de cette interview, il a été question d’utiliser Directory Server dans des rôles secondaires plutôt que directement en production. Pourtant, il y a un an, lors de l’ApacheCon 08, Emmanuel Lécharny s’était longuement attardé sur la question lors de sa présentation en mettant en avant les fonctionnalités exclusives de procédures stockées et de triggers pour légitimer l’utilisation de Directory Server en production. Face à l’oscillation autour de cette problématique, notons qu’Apache DS, pourrait, plus modestement, être utilisé conjointement à d’autres serveurs LDAP commerciaux par la mise en place d’un virtual directory.

Enfin, Emmanuel Lécharny a exposé une synthèse des principales nouveautés à attendre de la future version 2.0, actuellement prévue pour septembre :

• Réplication multi-master entre plusieurs noeuds Apache DS ainsi qu’avec des noeuds OpenLDAP.
• Disaster Recovery System permettant d’éviter les pertes de données suite à un crash. Cette fonctionnalité étant actuellement assurée par un journal, peu optimal, qui rend l’opération de récupération très longue.
• Configuration stockée au sein même du serveur LDAP.

La mémoire native en Java

Andrew Hall a publié deux articles très intéressants portant sur la gestion de la mémoire native dans la JVM, c’est-à-dire la mémoire consommée par la machine virtuelle mais ne faisant pas partie de la Java Heap et n’étant donc pas gérée par le garbage collector. Les systèmes d’exploitation couverts par ces articles sont Windows, Linux et AIX.

Après avoir fait un rappel sur la gestion de la mémoire par les systèmes d’exploitation, l’auteur explique en détail les différents composants Java susceptibles de consommer de la mémoire native non gérée au sein de la Heap Java. En font partie le bytecode des classes chargées par les classloaders, la mémoire allouée par le code JNI natif, les direct buffers NIO et les stacks de chaque thread. Le problème est que la mémoire totale adressable par un processus 32 bits est de 2 à 4 Go selon les cas. Des crashs de la JVM, dus à un manque de mémoire, peuvent donc parfois intervenir alors que la Java Heap n’est pas pleine.

Les solutions à cette problématique sont passées en revue, parmi lesquelles figurent : réduire la mémoire totale utilisée par la JVM en réduisant la taille de la Java Heap (via -Xmx), réduire l’utilisation de mémoire native non gérée par la Java Heap, repousser la taille limite de la mémoire adressable par le processus de la JVM en passant par exemple à un OS et une JVM 64 bits.

Au-delà des informations fournies par ces deux articles, les lecteurs intéressés par ce sujet pourront étudier le très complet, bien qu’ancien, livre de Bill Venners, ‘Inside the Java Virtual Machine’, partiellement disponible en ligne.

Actualité éditeurs / SSII

• Amazon lance son service Elastic MapReduce

Agilité

• Kanban vs Scrum

RIA

• Optimisation GWT : EntryPoint multiples

SOA

• Le calendrier se confirme pour jBPM

Le coin de la technique

• Les nouveautés du futur SpringSource dm Server
• Spring tc Server, c’est parti … en version beta

Actualité éditeurs / SSII

Amazon lance son service Elastic MapReduce

Un nouveau service, Elastic MapReduce, vient s’ajouter au catalogue Amazon. Basé sur EC2 pour la puissance de calcul et sur S3 pour le stockage, ce service permet de soumettre facilement des traitements sur un large volume de données à Amazon en s’appuyant sur le framework Apache Hadoop et son modèle de programmation MapReduce.

Par rapport au service EC2, Elastic MapReduce apporte une solution Hadoop clé en main. Ainsi, il suffit de fournir au service les données en entrée via S3 et un programme de traitement écrit soit en Java en utilisant l’API Hadoop, soit dans un autre langage grâce à Hadoop Streaming (Ruby, Perl, Python, PHP, R, ou C++). Les données produites lors du traitement sont également placées sur S3. Les jobs peuvent alors être créés et contrôlés soit depuis l’interface de management d’AWS, soit depuis une API SOAP.

Répondant à un besoin typique du cloud computing, ce service permet de se lancer dans des expérimentations de traitement distribué rapidement en délestant le développeur de toute tâche de configuration système préalable. Il est par ailleurs intéressant de noter cette mise en avant du framework Hadoop, issu du projet Nutch en 2006, qui bénéficiait déjà d’un large intérêt comme en témoigne les 3 livres qui lui seront consacrés d’ici la fin de l’année chez Manning, O’Reilly et Apress.

Agilité

Kanban vs Scrum

Sur son blog, Henrik Kniberg nous propose un document au sujet de Kanban et de Scrum. Cette première version de ce document nous explique, de manière simplifiée, les différences entre les implémentations. En voici quelques unes :

• Pas de définition de rôles dans le Kanban.
• Les estimations sont optionnels.
• Prioriser les items est optionnel.

Néanmoins, Kanban et Scrum présentent des similitudes :

• ce sont des processus d’optimisations.
• possibilité d’itérer sur plusieurs produits en même temps.

Au final, nous nous rendons compte que beaucoup de notions ne sont pas antinomiques, et selon les contextes il est intéressant de faire cohabiter certaines notions de Kanban et de Scrum.

RIA

Optimisation GWT : EntryPoint multiples

Les développeurs GWT se heurtent parfois à deux problèmes communs: un temps de compilation astronomique et des livrables très gourmands en taille.Heureusement, Matt Raible est là !

L’idée est de séparer votre application finale en plusieurs applications/écrans. Imaginons une application complète avec un seul EntryPoint qui contiendrait un front-office, un back-office et un écran standalone de statistiques : modifier le front-office impliquera la livraison de tous nos composants alors que les écrans back-office et statistiques n’ont pas été changés. Notre exemple ne contient que trois écrans différents mais selon le métier il est tout à fait possible d’envisager une dizaine d’écrans.

L’optimisation se passe sur le blog de Matt Raible avec l’article optimizing a GWT Application with Multiple EntryPoints. L’idée est simple : découper votre application en plusieurs mini-applications indépendantes (donc des écrans différents). La découpe se fera en créant plusieurs EntryPoints avec leur XML associé. On pourra alors ne compiler et ne livrer que le module souhaité (par exemple à l’aide d’un profil maven). On gagne alors en temps de compilation mais surtout en taille de livrable : ici on ne livre que ce qui doit être livré (to-be-released feature). Matt obtient alors sur son livrable un gain en taille de 56% (non négligeable).
La mise en place d’un tel découpage est simple : création d’un nouvel EntryPoint (classe java et gxt.xml), mise à jour des références dans le html et le nocache.js et enfin création d’un profil maven associé à votre entry point de release.

On peut recouper ce best-practice avec la modularisation d’une application GWT, celle-ci apportant en plus la notion de partage de module. On pourra alors créer des modules CommonsUI, StatsModule… qui seront des modules génériques pouvant être réutilisés par d’autres applications (inherit du gwt.xml). Cette pratique est très courante dans les projets GWT, mais la création d’EntryPoint de type livrable l’est déjà moins.

Avez-vous des retours concernant cette technique ?

SOA

Le calendrier se confirme pour jBPM

Le projet jBPM n’a pas connu de nouvelle version majeure depuis 2005. Pourtant ce moteur de BPM open-source très populaire fait partie de la suite JBoss Enterprise SOA Platform lancée début 2008.

La version 4 a été dévoilée en alpha en décembre dernier mais son temps de gestation particulièrement long, similaire au délai important qu’a connu JBoss AS 5, laissait planer le doute quant au calendrier. Tom Baeyens, project lead de jBPM, annonçait en début d’année l’arrivée d’une version finale pour juillet et a confirmé cette date lors d’une récente présentation au BeJUG. C’est maintenant l’équipe de JBoss Seam qui vient corroborer ce planing en annonçant l’arrivée de Seam 2.2 pour juin. Soit juste avant l’arrivée de jBPM 4 avec lequel il prévoit de s’intégrer par la suite.

Le temps de développement particulièrement long de cette nouvelle version est probablement imputable au très ambitieux module PVM (Process Virtual Machine), dont le principe a été conçu conjointement avec OW2 et son projet équivalent Bonita. Le but de PVM est d’offrir un moteur d’exécution de processus générique servant de base commune pour l’implémentation des différents langages de définition de workflow (jPDL, BPEL, Pageflow, …) supportés par jBPM. L’API de PVM reste malgré tout accessible par les développeurs souhaitant définir leurs workflows directement en Java.

Outre PVM, les autres nouveautés notables de cette version 4 seront :

• La possibilité d’utiliser BPMN dans l’éditeur graphique sous Eclipse.
• Une évolution de l’API de gestion des activities permettant un meilleur découplage.
• Un schéma de base de données plus évolutif et partitionné selon les langages de définition de processus.

Rendez vous est pris pour juillet.

Le coin de la technique

Les nouveautés du futur SpringSource dm Server

SpringSource dm Server était le produit phare mis en avant lors de SpringOne Europe 2008 de juin dernier. OSGi était alors omniprésent dans les présentations. Pourtant 9 mois après sa sortie, les débouchés ne semblent toujours pas évidents. Ceci est avant tout dû à OSGi, qui reste une technologie méconnue et dont l’introduction dans le monde du Java d’entreprise pose encore quelques problèmes en raison du modèle particulier de découpage en bundles qu’il impose.

SpringSource a présenté récemment la liste des nouveautés prévisionnelles de son dm Server 2, prévu pour juillet. Visiblement conscient des problèmes que pose OSGi, SpringSource propose plusieurs améliorations :

• Clonage de bundle : cette fonctionnalité, activée par défaut, entraînera le chargement automatique d’une seconde instance identique d’un bundle lorsqu’un conflit dû à une clause uses sera détecté. Un clone pourra également être créé manuellement pour palier au comportement de certains frameworks utilisant des variables statiques et dont le bundle se prête donc mal au partage
• Gestion des logs : elle sera revue dans la prochaine version pour permettre une configuration centralisée par application et permettra à un bundle partagé entre plusieurs application d’écrire dans le fichier de log adapté au contexte
• Bundlor : un outil de création automatisée de bundles, développé conjointement, et dont nous vous parlions la semaine dernière

Du reste des nouveautés, on retiendra surtout l’alignement avec les RFCs de l’OSGi Alliance, coïncidant ainsi avec le planning initialement prévu.

Spring tc Server, c’est parti … en version beta

Nous avions annoncé en Décembre 2008 le lancement de Tc Server, la version professionnelle de Tomcat par Spring Source. La version beta est désormais disponible. Pour mémoire, Tc Server apporte du support commercial, une simplification des installations, des outils de diagnostique avancé et des outils d’administration centralisés avec interface graphique et ligne de commande. Voici nos première impressions :

Aide au diagnostique

Tc Server apporte à Tomcat Standard des outils de diagnostique qui n’ont rien à envier à ceux qu’on trouve sur les gros serveurs JavaEE commerciaux. Nous retiendrons :

• La configuration JMX dans server.xml + catalina.properties (plutôt que dans setenv.sh) qui permet de surcroît de préciser le port d’écoute pour passer les firewalls (cf Daniel Fuchs blog : Connecting Through Firewall Using JMX – Without modifying the server application)
• La détection des requêtes HTTP lentes avec le détails des activités de Garbage Collection et d’accès Data Source (les accès web services sont prévus).
• Un mécanisme de First Failure Data Capture (heap dump, threads dump, état des composants Tomcat) pour les requêtes HTTP en erreur.
• La détection des requêtes SQL lentes, des deadlocks inter-threads et de durée de Garbage Collection excessive

Installation

L’installation reprend les bonnes pratiques Tomcat de séparer les binaires tomcat (CATALINA_HOME) des configurations des instances (CATALINA_BASE) et de grouper les paramètres spécifiques à chaque instance dans catalina.properties. Ce mode d’installation facilite grandement les montées de version de Tomcat ou de JVM et la gestion de plusieurs instances Tomcat voisines.

Le tuning des configurations JVM (setenv.sh) et Tomcat (server.xml) est très pédagogique.

Le script de création des instances ne prend en compte pour le moment ni l’incrément automatique des ports d’écoute (pour ne pas collisionner avec les instances voisines) ni la configuration Apache Httpd (mod_proxy_http) qui sont en amont des Tomcat.

Nous n’avons pas trouvé la commande tcadmin.sh qui permet de gérer les groupes de serveurs. La documentation semble en avance sur le produit livré ; c’est assez rare dans le monde du logiciel .

Administration et Spring AMS

Spring AMS Tc Server est une extension du socle déjà mature Spring AMS qui est lui même basé sur Hyperic. Nous noterons comme bémol qu’AMS repose sur une ancienne version d’Hyperic, qu’il n’est pas possible de déployer les plugins Spring AMS dans Hyperic et que l’inverse est certes possible mais demande un travail autant contractuel que technique d’installation. La solution la plus humble est de faire cohabiter un Spring AMS (serveur + agents) dédié aux serveurs Java EE aux côtés d’un Hyperic (serveur + agents) dédié aux autres composants à superviser.

Pour revenir sur Spring Tc Server, nous remarquerons la configuration par console graphique AMS des serveurs Tc Server avec ses judicieux conseils de paramétrages (le déploiment de configuration ne supprime pas les commentaires dans server.xml). Les alertes deadlock et temps de garbage collection excessifs sont remontés dans Spring AMS.

Au final, cette version beta est bien agréable pour les afficionados de Tomcat. La documentation est bien entamée, les fonctionnalités intéressantes et l’ensemble très pédagogique pour les connaisseurs. Ces qualités techniques se transformeront-elles en déploiement dans nos data center ? Il faudra convaincre les exploitants du bien fondé de passer d’un modèle open source gratuit à de l’open source professionel …

Actualité éditeurs / SSII

• Sun, Java et le JCP
• RIA, SOA, Tim Bray tire dans le tas

SOA

• Red Hat JBoss choisit d’investir dans CXF

Le coin de la technique

• Enfin une roadmap détaillée pour le JDK7
• La création de bundles OSGi selon SpringSource
• Utiliser le nuage pour réduire les coûts d’intégration continue.
• Outils Glassfish pour Eclipse

Actualité éditeurs / SSII

Sun, Java et le JCP

Depuis quelques jours, une agitation se crée au sein de la communauté Java autour des agissements de Sun vis-à-vis de son projet OpenJDK 7. Plusieurs observations permettent en effet de penser que le JDK 7 pourrait bien ne pas être basé sur un standard du JCP comme c’est habituellement le cas :

• Neil Bartlett remarque que le projet Jigsaw, poussé par Sun pour être le système de modules utilisé par le JDK, n’est pas défini par une JSR. Ceci en fait donc une technologie propriétaire dont il doute de la légitimité face à OSGi, un standard bénéficiant de 10 années d’expérience.
• Stephen Colebourne constate que Sun ne fait plus mention de « Java 7″ depuis quelques temps, mais seulement de « JDK 7″ qui n’est qu’une implémentation, là où « Java 7″ qualifierait un standard.
• Anne Thomas Manes faisant des observations similaires, compare l’OpenJDK à la position de framework Open Source « rebelle », non standard, que tient Spring.
• Stephen Colebourne encore, visiblement très impliqué par ce débat, revient dans une série de billets sur les différents qui opposent Sun à la fondation Apache, rappelant l’historique, ainsi que sur la problématique de propriété intellectuelle au sein du JCP de manière générale.

Si le JDK 7 devait être finalisé sans qu’aucun standard ne le soutienne, cela constituerait un évènement majeur, puisque l’avenir deviendrait incertain pour les JVMs fournies par d’autres éditeurs tels qu’Oracle ou IBM.

RIA, SOA, Tim Bray tire dans le tas

C’est dans une interview pour InfoQ que Tim Bray co-auteur du XML nous donne son avis sur les technologies RIA. Selon lui, les RIA type Flex, Silverlight et JavaFx n’ont pour but que de fournir des applications toujours plus immersives et de moins en moins utiles. Il modère tout de même ses propos en s’appuyant sur des exemples de réussite comme Google et Yahoo! qui utilisent de manière élégante Ajax et consort. En bref, pour lui les avantages des interfaces web sont la simplicité et la rapidité, Tim ne croit donc pas en la longévité du RIA. Rien de mieux pour faire de l’applicatif lourd que de l’applicatif lourd.
Dans son interview, il explique rapidement que l’émergence des Web Services et des architectures de type SOA s’est faite en dépit du bon sens. Au début chacun y allait de son format XML privé et ça fonctionnait, mais on a voulu généraliser le problème et fournir une solution pour tous. Cette volonté de créer une pierre philosophale pour exposer ses services n’a apporté que des difficultés d’implémentation, d’intégration et surtout d’interopérabilité. Bref, Tim est assez pessimiste en ce qui concerne les ‘WS-*’, il soutient en revanche REST qui selon ses termes, n’est qu’une reformulation des bonnes pratiques des Web Oriented Architectures.
Enfin, il reste très discret sur Sun et sur le cloud computing en indiquant tout de même que pour le moment le département se cherche un peu. Faut-il fournir des solutions et des outils pour implémenter des nuages ou bien héberger directement des nuages et devenir fournisseur?

L’interview complète sur InfoQ
La réponse de Yakov Fain

SOA

Red Hat JBoss choisit d’investir dans CXF

Red Hat a annoncé la semaine dernière qu’elle devient un « key contributor » du projet Apache CXF.
A terme, comme l’explique Sacha Labourey sur son blog, cela signifie que JBossWS qui laisse aujourd’hui le choix de l’implémentation Web Service (ne fournissant qu’une couche d’abstraction) ne fournira plus que l’implémentation Apache CXF. C’est dommage, d’autant plus que les dernières releases de CXF ont été plutôt douloureuses et riches en bugs.
D’un autre côté, la participation active des équipes JBoss au projet ne peut qu’aider à rectifier le tir. Gageons donc que les futures releases d’Apache CXF seront de bien meilleures factures que celles de 2008.

Le coin de la technique

Enfin une roadmap détaillée pour le JDK7

Lors de la conférence Devoxx de décembre dernier, un keynote avait particulièrement retenu l’attention : Mark Reinhold présentait alors la liste des fonctionnalités qui seraient intégrées au futur JDK 7, ainsi qu’une date pour la version finale.

Mark Reinhold annonce maintenant la mise en ligne d’un calendrier détaillé des milestones prévus et des fonctionnalités associées.

L’analyse de ces informations aboutit à quelques remarques :

• La période annoncée en décembre dernier pour l’arrivée d’une version finale, à savoir « début 2010″, est légèrement décalée puisqu’un final milestone est prévu pour le 18/02/2010 suivi d’une phase de release candidate d’un à deux mois. Ceci porterait donc l’arrivée d’une version finale à avril ou mai 2010.
• La liste des nouveautés reste globalement inchangée à une exception près : il n’est plus question de MVM (Multiple Virtual Machines) qui devait permettre d’exécuter plusieurs applications au sein d’une même VM. Cette fonctionnalité, particulièrement intéressante dans le contexte du regain d’intérêt pour les Applets Java et autres applications JavaFX embarquées dans le browser, était annotée d’un « maybe » il y a deux mois et était visiblement trop ambitieuse pour résister à la pression du calendrier.
• La JSR-310 (Date and Time API) n’avait pas été citée en décembre et ne l’est toujours pas. L’appel à l’aide du spec lead Stephen Colebourne aura donc été vain. En effet, comme il le faisait alors remarquer, dans le cas d’une inclusion au JDK, JDBC et NIO2 seraient impactés afin de prendre en compte la nouvelle API. Compte-tenu de cet impact, il était essentiel que cette JSR puisse être finalisée rapidement. Or son statut, toujours annoncé comme « inactive » par le site du JCP, tend à nous faire penser que la classe java.util.Date a encore de « beaux » jours devant elle.

La création de bundles OSGi selon SpringSource

SpringSource annonce l’arrivée de Bundlor, son outil de création de bundles OSGi, actuellement en version 1.0M2.

Dans un projet OSGi il est en effet nécessaire que l’ensemble des modules de l’application et des librairies tierces soient fournis sous forme de bundles. La création de bundles pour les modules dont on a le contrôle n’est pas un problème en soit, pour les librairies tierces, il en est tout autrement.

Deux possibilités s’offrent alors au développeur : obtenir la librairie qu’il recherche packagée sous forme d’un bundle OSGi sur un repository dédié (celui de SpringSource par exemple) ou créer ce bundle par lui-même. Dans ce dernier cas, il faudra analyser l’ensemble des dépendances de la librairie pour créer un manifest adapté. C’est là que les outils de création automatisée de bundles interviennent. Bnd était le seul disponible jusqu’alors, crée par Peter Kriens, Technical Director d’OSGi. SpringSource amène donc désormais son propre outil.

Bundlor est justifié par SpringSource par quelques fonctionnalités non présentes dans Bnd telles que la création incrémentale de manifests et l’intégration à Eclipse via un plugin dédié.

Malgré l’apparente efficacité de ce type d’outil, il est indispensable de ne l’appliquer qu’à des librairies tierces. En effet un des intérêts d’OSGi réside dans sa capacité à n’exposer qu’une partie soigneusement sélectionnée des interfaces d’un module, ce que seule une intervention humaine sera à même d’effectuer correctement.

Utiliser le nuage pour réduire les coûts d’intégration continue.

Il est de notoriété publique que plus la fin d’un sprint approche, plus les ressources du serveur d’intégration sont sollicitées. En outre, c’est dans ces périodes que les développeurs ont besoin des feedbacks les plus rapides. Alors, que faire ? S’offrir une machine surpuissante, dédiée à l’intégration continue, mais qui ne sera que rarement utilisée à pleine capacité ?
Atlassian, l’éditeur du serveur d’intégration continue Bamboo, propose de résoudre ce problème dans la version 2.2 de son produit, en offrant la possibilité d’utiliser « Elastic Bamboo », un agent distant s’exécutant sur le nuage Amazon EC2. Ainsi, la disponibilité et la puissance sont maximales lorsque l’équipe en a besoin, tout en limitant les coûts.
Et comme Atlassian utilise Bamboo en interne, certains plâtres sont déjà essuyés :

• Les builds doivent réellement être indépendants de l’environnement (à vous de construire vos builds en étant conscients de ce problème).
• Dans le cas standard, les dépendances doivent être téléchargées à chaque build (l’instance de build disparaissant du nuage lorsqu’elle se termine). Une solution peut être d’utiliser une image disque sauvegardée sur le nuage.

Toutes les astuces de Edwin Wong pour paramétrer votre serveur d’intégration continue sur le nuage se trouvent sur le blog d’Atlassian.

Outils Glassfish pour Eclipse

Sun vient de sortir la version 0.9 (la version 1.0 arrive bientôt) de son bundle.
Celui-ci intègre:

• Eclipse 3.4.1
• Serveurs Glassfish v 2.1 et v3 Prélude
• JDK 1.6 Update 12 (optionnel)
• Une série de plugins permettant de configurer votre serveur J2EE, ainsi que vos WebServices (Soap ou Rest) depuis l’IDE. (Plus de détails sur les plugins, ici).

Ce bundle offre l’avantage de fournir un paquet tout-en-un. Il est destiné aux développeurs et aux organisations qui n’utilisent pas NetBeans, mais Eclipse. Celui-ci étant l’IDE le plus répandu. Sun élargit ainsi son public et se rapproche de la grande communauté d’Eclipse.

Actualité éditeurs / SSII

• Coopération entre SpringSource et Adobe
• tc Server : SpringSource signe la première offre open source professionnelle sur Tomcat

Le coin de la technique

• Les orientations de GWT : Roadmap GWT 1.6
• Java 7, ce n’est pas pour tout de suite…
• Sortie de Grizzly 1.9
• Présentation de Google Guice 2.0

Actualité éditeurs / SSII

Coopération entre SpringSource et Adobe

SpringSource renforce son positionnement sur les RIA en signant un accord de partenariat avec Adobe Systems. Un partenariat dont l’objectif est de simplifier le développement et le déploiement des applications RIA se basant sur Adobe Flex et Spring.

Adobe et SpringSource se sont alliés pour travailler sur Spring BlazeDS Integration, un projet open source qui vise à simplifier l’intégration de Spring avec Adobe’s BlazeDS. Une version bêta est prévue dans une ou deux semaines.

SpringSource a prévu pour l’année prochaine un nouvel adaptateur pour Adobe LiveCycle Data Services ES, qui permet d’instaurer un moteur d’échanges de données entre les applications RIA basées sur Flex et Spring.

Ce rapprochement permet à SpringSource de renforcer son positionnement sur les RIA.

tc Server : SpringSource signe la première offre open source professionnelle sur Tomcat

Philip Hanik présente dans « SpringSource tc Server – The Tomcat you know. The enterprise capabilities you need. » le périmètre du nouvellement annoncé tc Server.

On y retrouve tous les ingrédients de la version commerciale d’un produit open source professionnel :

• Support : de l’entrée de gamme « heures ouvrées » à la formule « mission critique 24×365″ avec une réponse dans l’heure
• Packaging : livraison packagée avec les patchs nécessaires au client et des configurations et scripts de démarrage optimisés pour les différentes plateformes (32 vs 64 bits, etc).
• Indemnisation : en cas de problème juridique concernant la nature Open Source de Tomcat.
• Administration centralisée : ajout de mécanismes de gestion centralisée de serveurs Tomcat (configuration des serveurs, déploiement d’applications clusterisées [1] )
• Audit : suivi des opérations réalisées sur les serveurs.
• Monitoring et alertes : reprise des fonctionnalités de SpringAMS ( Hyperic HQ + extensions de monitoring de Spring Framework).
• Diagnostique : détection de thread lock, corrélation des erreurs avec les urls et les threads, mécanisme de First Failure Data Capture (FFDC).

Si les premiers points étaient déjà couverts par des offres de support commercial (e.g. SpringSource Enterprise Ready Server), c’est la première offre de type Open Core Licensing pour Tomcat (noyau open source + extensions commerciales orientées administration).
Les éditeurs incitaient jusqu’à présent leurs clients intéressés par un support Tomcat à faire un upsale sur serveur plus sophistiqué (JBoss App. Server, Websphere App. Server Community Edition, Spring dm Server, etc).

Quel intérêt de payer 500$/an/cpu pour tc Server plutôt que d’utiliser Tomcat ? Outre le support qui sera important pour de nombreux exploitants, les fonctionnalités d’exploitations et de supervision présentent un intérêt à prendre en compte.

Nous noterons pour conclure que l’ensemble des fonctionnalités annoncées ne sera pas disponible dès la version 1.0 de tc Server.

[1] tc Server permet notamment des opérations install/update/start/stop/uninstall/rollback phasées sur des clusters pour mettre à jour les noeuds les uns après les autres sans arrêt du service.

Le coin de la technique

Les orientations de GWT : Roadmap GWT 1.6

La version actuelle de GWT est la 1.5.3. L’équipe GWT a présenté sur son blog officiel les orientations de GWT 1.6 et des prochaines versions : What’s ahead for Google Web Toolkit.

Ainsi, on observe que l’équipe GWT s’attaque à différents points :

• Performance
• De compilation pour améliorer la productivité du cycle de développement
• D’exécution : optimisation de l’utilisation de la classe StringBuilder par exemple, des composants (cf LazyPanel plus bas)
• S’approcher des bonnes pratiques éprouvées dans la communauté Java : voici la spécification : Design Doc for 1.6 WAR structure. Ainsi, il sera possible de livrer les fichiers statiques (images, css) dans un répertoire hors de la WebApps. Actuellement tout est chargé via le classpath. Ces ressources statiques pourront être « akamai-llisées » et aussi relivrées indépendamment de la WebApp.
• Richesse des composants : intégration de nouveaux composants qui étaient dans l’incubateur de composants GWT
• Un calendrier : DatePicker
• Un Panel qui permet l’affichage du contenu d’un Panel lorsqu’on le souhaite afin d’améliorer les performances d’affichage : LazyPanel
• Migration de Tomcat à Jetty pour le Hosted Mode Server.

Cette version 1.6 est prévue pour le premier trimestre 2009.

Ils parlent aussi de la Roadmap GWT :

• Marwan KHELIF avec GWT 1.6 : quoi de neuf ?
• Thomas Recloux avec Roadmap GWT 1.6
• A voir aussi sur le site officiel de GWT Making Gwt Better

Java 7, ce n’est pas pour tout de suite…

Initialement prévu pour début 2009, nous n’avons toujours pas (peu) eu de détails officiels concernant celui-ci. Vous vous en doutiez, Java 7 ne sortira pas demain. Suite à une des conférences de Devoxx, nous en savons désormais un peu plus sur ce sujet : sa sortie décalée à début 2010.

Est-ce si lointain ? Pas vraiment, à la vue de tous les différents qui tournent autour du Jdk 7 (modularité, closures …), il ne sera probablement pas trop d’une année pour résoudre tous ces sujets de discordes. Pour y arriver, des choix rapides et judicieux devront être pris, cette même conférence en a d’ailleurs laissé sous-entendre quelques-uns, en voici les grandes lignes.

• Modularité : point central de Java7, après la mort programmée de la JSR-277, la réconciliation avec OSGi devra sans doute passer par la JSR-294 (sous-jacente) – les superpackages. Si quelques changements récents offrent des perspectives de réconciliation, l’aventure ne fait que commencer pour le sujet le plus sensible du Jdk 7. Le nouveau projet Jigsaw qui doit permettre de partager à la communauté l’avancement des travaux est déjà fortement controversé.
• Les closures : la grande blague ; le jdk7 ne proposera finalement pas cette fonctionnalité. Aucun consensus n’ayant été trouvé à ce sujet par la communauté : celles-ci sont pour le moment déscopées.
• Les nouvelles API : aucun scoop à ce sujet. Nous en connaissions déjà les principales : nio2 (JSR-203) et JodaTime (JSR-310).
• Évolutions du langage : C’est Joseph D. Darcy qui sera chargé de définir et regrouper les petites évolutions du langage pour le Jdk 7. Pour cette future nouvelle JSR (sa 3e après JSR-13 et JSR-269), il a prévu d’impliquer d’avantage la communauté pour ce point facilement sujet à controverse. Son idée est de proposer et demander les retours de la communauté en amont du processus pour éviter toute controverse. Avant même que la JSR ne soit proposée en draft, les grandes lignes de celles-ci devraient en être définies, disponibles et discutées sur un projet spécifique de l’open JDK. Cette JSR est prévue pour sortir au cours du premier semestre 2009.

À ce propos, vous vous demandez peut-être comment va-t-il s’y prendre pour intégrer ces changements ? C’est peut-être également l’occasion de revenir sur un de ces anciens articles présentant les différentes étapes à suivre pour ajouter des fonctionnalités dans le jdk .

Sortie de Grizzly 1.9

Grizzly 1.9 est sorti, à noter que la version 2.0 est prévue pour la fin de l’année. Grizzly est un framework Sun pour aider les développeurs à construire des serveurs robustes et scalables en utilisant l’API Java NIO (et NIO 2). Il met aussi à disposition le support de différents protocoles :

• Glassfish utilise Grizzly comme HTTP Listener.

  Les nouveautés de cette version sont :

  • Support des I/O asynchrones (NIO2, Xebia en avait parlé), cela permet d’améliorer grandement les performances
  • Support des HTTP write asynchrones
  • GrizzlyAdapterChain supporte maintenant plusieurs adapteurs et peut transformer les requêtes d’entrées à la volée
  • Le framework Comet a amélioré ses performances. À voir aussi un exemple d’implémentation utilisant GrizzlyComet : Writing a Twitter like application using Grizzly Comet part 1: The Servlet.

  Présentation de Google Guice 2.0

  La sortie Guice 2.0 est attendue pour décembre 2008 donc très prochainement.

  À l’image de Spring, Guice est un framework d’injection de dépendances. Cependant, Guice se démarque de Spring dans la mesure où Guice fonctionne sans aucun XML. La configuration et le tissage des dépendances se font de manière programmatique. Il utilise les annotations du langage Java 5.

  Guice se veut être un framework léger et facile à intégrer. Il existe d’ailleurs un plugin Struts pour gérer l’injection de dépendances en Guice.

  L’article Dependency injection with Guice de Nicholas Lesoecki, employé à Google, présente le fonctionnement de Guice.

  Voici le fonctionnement du Guice d’un point de vue programmatique :

  @Inject
  public FrogMan(Vehicle vehicle) {
    this.vehicle = vehicle;
  }
  

  Le tissage s’effectue aussi de manière programmatique, ce qui le différencie radicalement de Spring :

  public class HeroModule implements Module {
    public void configure(Binder binder) {
      binder.bind(Vehicle.class).to(FrogMobile.class);
    }
  }
  

  Le tissage est donc réalisé dans un Module.

  Ensuite le contexte Guice se démarre comme suit :

  public class Adventure {
    public static void main(String[] args){
      Injector injector = Guice.createInjector(new HeroModule());
      FrogMan hero = injector.getInstance(FrogMan.class);
      hero.fightCrime();
    }
  }
  

  Il est possible d’injecter une dépendance par :

  • Constructeur, c’est la méthode la plus simple, par forcément la plus élégante en Spring
  • Méthode
  • Attribut de classe

  Cependant, un problème peut se poser par rapport à l’exemple précédent : comment injecter plusieurs véhicules ? Solution : il faut nommer les cibles en créant ses propres annotations pour l’injection :

  @Inject
  public WeaselGirl(@Fast Vehicle vehicle) {
    this.vehicle = vehicle;
  }
  

  Code source du tissage :

  public class HeroModule implements Module {
   public void configure(Binder binder) {
      binder.bind(Vehicle.class).to(FrogMobile.class);
      binder.bind(Vehicle.class).annotatedWith(Fast.class).to(WeaselCopter.class);
    }
  }
  

  Code source de la déclaration de l’annotation :

  @Retention(RetentionPolicy.RUNTIME)
  @Target({ElementType.FIELD, ElementType.PARAMETER})
  @BindingAnnotation
  public @interface Fast {}
  

  Les nouveautés de cette version sont présentées sur le site officiel : Changes in Guice 2. On y trouve entre autre :

  • Implémentation de l’AOP
  • Surcharge du binding d’un module à un autre
  • Binding des éléments d’un tableau Set ({{Multibinding}}) ou Map ({{Mapbinding}})
  • Convertisseur de type branchable, par exemple, pour convertir une chaîne de caractères en date

  Même si Guice est loin d’avoir la maturité de Spring ou même autant de fonctionnalités que ce dernier, il propose une approche de l’injection de dépendances très pragmatique.

  Une étude sur la comparaison des versions Guice 1.0 et Spring 2.0.2 (Guice vs. Spring JavaConfig: A comparison of DI styles) arrive aux conclusions suivantes :

  • Performance : Guice est plus rapide, mais est-ce vraiment important car généralement les dépendances sont chargées au démarrage de l’application ?
  • Modèle de programmation Guice plus intrusif : il est dommage de devoir mettre un @inject dans les objets Guice qui peuvent être injectés
  • Spring AOP est plus puissante
  • Guice est plus facile à intégrer (il y a seulement 2 Jars à intégrer)

  À voir également : deux liens intéressants sur l’injection de dépendance issus de la documentation de PicoContainer, autre implémentation pour l’injection de dépendance :

  • Design patterns, règles a avoir en tête lorsque l’on fait de l’injection de dépendance
  • Inversion of Control history, tout sur l’injection de dépendance
  ]]> http://blog.xebia.fr/2008/12/15/revue-de-presse-xebia-87/feed/ 4 http://blog.xebia.fr/2008/12/08/revue-de-presse-xebia-86/ http://blog.xebia.fr/2008/12/08/revue-de-presse-xebia-86/#comments Mon, 08 Dec 2008 18:13:36 +0000 Xebia France http://blog.xebia.fr/?p=1112
  La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

  Actualité éditeurs / SSII

  • JBoss AS 5, ce fut long mais c’est parti
  • SpringSource tc Server : un dm Server sans ses modules
  • Quoi de neuf dans Spring 3.0 M1 ?
  • Sortie de Spring Integration 1.0.0
  • Sortie d’Hibernate Search 3.1

  Agilité

  • L’agilité chez IBM

  RIA

  • Au pied du sapin : JavaFX GA
  • Silverlight sous Linux

  Le coin de la technique

  • Nouveau mode hosté pour GWT 2.0

  Actualité éditeurs / SSII

  JBoss AS 5, ce fut long mais c’est parti

  Sacha Labourey, CTO de JBoss, nous avait parlé lors de sa venue au Paris JUG la semaine dernière de l’imminence de cette annonce que la communauté attendait depuis longtemps : JBoss AS 5 est enfin releasé !

  Les principaux composants de JBoss AS 5

  • JBoss Micro Container (MC) : remplaçant du JMX Kernel, MC est le conteneur du serveur d’applications. Il offre le cycle de vie des différents modules (installation, démarrage, arrêt, désinstallation).
  • JBoss Messaging (JMS) : déjà utilisé dans JBoss AS 4, JBoss Messaging est le successeur de JBoss MQ. La version 2 de JBoss Messaging est en cours de développement; les synergies avec Red Hat Messaging sont prévues ; les efforts pour faire converger les deux middlewares de message seront vraisemblablement importants.
  • JBoss Transaction : issu du rachat d’Arjuna Transaction Service en 2005, ce composant mature n’a pas connu d’évolution significative avec AS 5.
  • JBoss WS : stack Web Service ; la multiplicité de ses implémentations SOAP (native, adapteur pour Glassfish Metro ou pour Apache CXF) rend compliquée la compréhension de ce composant.
  • Clustering : la haute disponibilité et la réplication reposent sur le mature et dynamique JBoss Cache (aujourd’hui en version 3) qui repose lui-même sur la librairie de communication multicast JGroups.
  • JBoss Web : fort de son long passé de commiter Tomcat, JBoss package sa version optimisée du moteur de servlet de la fondation Apache.

  Pourquoi JBoss a-t-il mis autant de temps à sortir cette version ? Des difficultés pour implémenter Java EE 5 ?
  JBoss n’a pas eu de difficultés particulières à implémenter les EJB 3 ou JPA qui étaient déjà disponibles dans JBoss AS 4.2. Java EE 5 est la partie émergée de l’iceberg AS 5. Ce qui a pris du temps à JBoss est la refonte complète de son serveur d’applications. Les fonctions structurelles du middleware (transactions, clustering, messaging, sécurité, administration, etc.) sont désormais séparées des applications déployées qui peuvent être packagées au format Java EE mais aussi OSGi, Spring, Ruby On Rails ou tout autre format dès lors qu’un deployer (i.e. adaptateur) est disponible.

  JBoss Micro Container est-il une victime du syndrome Not Invented Here ?
  La réponse est complexe et le choix de JBoss plein de mesure. Le projet MC a été lancé alors que la bataille (plus politique que technique) entre Java Module System et OSGi faisait rage. Sun misait sur le projet HK2 pour son serveur Glassfish et s’est finalement rabattu sur le conteneur OSGi Apache Felix. SpringSource a tellement amélioré OSGi que le résultat rendait OSGi méconnaissable (adieux les ServiceTracker et autres Declarative Services) ; le pari a réussi et Spring dm Server est en cours de standardisation par l’OSGi Alliance sous le nom de Blueprint Component Model. JBoss, pourtant habitué des contributions aux standards Java (cf. JPA, Web Beans, etc.) a cette fois ci préféré commencer cavalier seul avec un Micro Container qui supporte OSGi comme il aurait pu supporter Java Module System.

  Si JBoss AS 5.0 est une refonte complète, il risque d’être buggué
  Le risque n’est pas nul, mais nous remarquerons que la plupart des composants fondamentaux sont matures et n’ont pas été impactés par la refonte 5.0 (transactions, messaging, etc.).

  Le chantier AS 5 a-t-il été trop ambitieux ?
  Les autres serveurs d’applications ont déjà été refondus (Websphere 6.1) ou sont en cours de refonte (Glassfish 3). Cette remise à plat était importante. Cependant, JBoss a pris beaucoup plus de temps qu’il ne le prévoyait et a dû changer certaines méthodes de travail pour atteindre son objectif. Sacha Labourey a notamment expliqué que le mécanisme de build a été changé en cours de route et que le travail open source collaboratif à distance par forum/mailing-list interposés avait touché ses limites.

  Les clients ont-ils perdu patience ? Ont-ils changé de serveur ?
  Les clients ont sûrement été déçus par l’attente mais pas tellement plus que les clients Websphere et JBoss AS 4 proposait déjà les EJB 3 et JPA. Ensuite, Glassfish a surement pris des parts de marché à JBoss AS mais c’est plus probablement lié à l’essor de Glassfish qui se fait au détriment de ses concurrents JBoss, Websphere et Weblogic.

  En conclusion, JBoss AS 5 est une bonne nouvelle pour l’Open Source Java et rappelle la vitalité du modèle économique du Professional Open Source que JBoss a contribué à inventer.

  SpringSource tc Server : un dm Server sans ses modules

  L’actualité Spring est particulièrement riche cette semaine : SpringSource a annoncé lors des conférences de SpringOne Americas l’arrivée prochaine d’un nouveau serveur d’applications : le tc Server. Non, il ne s’agit pas d’un second renommage de leur dm Server, mais bel et bien d’un nouveau produit. Comme son nom l’indique, tc Server n’est ni plus ni moins qu’un Tomcat gonflé en fonctionnalités et en support, permettant de répondre aux problématiques de production.

  Selon SpringSource, ce nouveau serveur est destiné à trois types d’utilisateurs :

  • Les utilisateurs de Tomcat, désireux d’acquérir du support en production et/ou des fonctionnalités supplémentaires d’aide à la configuration et de diagnostics.
  • Les utilisateurs de serveurs d’applications JEE qui n’utilisent pas d’EJB, désireux de migrer vers une solution plus légère.
  • Les futurs utilisateurs de dm Server, désirant modulariser leur application.

  Par ailleurs, SpringSource a récemment annoncé dans sa roadmap une compatibilité Tomcat dans sa prochaine version de dm Server (Jersey) prévue pour Q2 2009. À terme, ces deux serveurs ne risquent-ils pas de se marcher dessus ? Vu de l’extérieur, cela donne l’impression que ce nouveau tc Server a été créé dans le but de rassurer les utilisateurs : pas besoin d’être modulaire pour tourner sur une plateforme SpringSource.

  Ce chevauchement dans l’offre nous laisse entrevoir une stratégie intéressante de la part de SpringSource :

  1. Attirer en douceur les utilisateurs via un simple support Tomcat avec tc Server.
  2. Les aiguiller par la suite vers une solution plus complète basée sur dm Server.

  Pour cela, Spring compte tout d’abord mettre en avant ses fonctions Java EE classiques (monitoring avancé, transactions distribuées), puis, dans un deuxième temps, ouvrir le développement sur un modèle de composants Spring Module. Tout l’enjeu de cette stratégie est de convaincre les exploitants. Une fois que dm Server sera suffisamment bien implanté, les développeurs devraient se mettre à déployer leurs propres modules OSGi.

  Cette distinction, techniquement non nécessaire, nous montre encore à quel point la monétisation du libre et la vente de support restent difficiles. La tarification des services reste au centre de la stratégie (et c’est bien compréhensible) : avec ce nouveau serveur, SpringSource nous propose également une nouvelle grille de tarifications allégée.

  Quoi de neuf dans Spring 3.0 M1 ?

  Le premier milestone du Spring nouveau est arrivé, annoncé par Jurgen Holler ce vendredi sur son blog. Comme nous l’annoncions dans une précédente revue de presse, Spring 3.0 M1 sort avec un léger retard par rapport à la roadmap Spring prévue.

  Utilisateurs de Spring 2.5, les nouveautés apportées par cette nouvelle version ne devraient pas vous dépayser : peu de nouveautés fonctionnelles, mais un gros travail de refactoring interne.

  Modifications techniques internes :

  • Migration de gestionnaire de source : CVS vers SVN, dont voici l’adresse.
  • Refactoring du projet en modules, le trunk contient une vingtaine de sous projets : org.springframework.core, org.springframework.aop, org.springframework.expression …
  • Chaque module est commité avec sa configuration Eclipse prête à l’emploi, vous trouverez donc les .project, .classpath et même les répertoires .settings directement sur le svn.
  • Vous y trouverez également les fichiers de configuration de build Ivy et un début de configuration Maven. Cette dernière n’est probablement pas fonctionnelle : les derniers commits datent de fin d’octobre pour les fichiers Maven, alors que des modifications ont été effectuées plus récemment fin novembre sur la configuration Ivy. D’ailleurs, les .classpath ne vous y tromperont pas, ils contiennent tous la variable d’environnement IVY_CACHE.
  • Refactoring des sources, chaque module utilise maintenant les fonctionnalités Java 5, le code interne en est simplifié.
  • Montée de version des tiers frameworks : JRuby 1.1 et JUnit 4.5. La montée de version de JUnit simplifie l’utilisation de ses extensions.

  Nouvelles fonctionnalités :

  • Arrivée de Spring EL utilisable dans n’importe quel composant Spring (y compris ‘core’). Vous pouvez par exemple utiliser la syntaxe #{ … } lors de la définition de vos beans (XML et/ou annotations) pour permettre de définir au runtime la valeur de certaines propriétés de vos beans prototypes.
  • Support de REST intégré dans Spring MVC.
  • … le reste à venir dans les milestones M2 et M3 qui suivront, prévus pour Q1 2009.

  Nous avions également publié un article en octobre présentant les principales nouveautés de Spring 3.0.

  Sortie de Spring Integration 1.0.0

  La version 1.0.0 GA de Spring Integration, le « light weight ESB«  de SpringSource a été annoncée cette semaine lors du dernier SpringOne Americas.

  Comme nous l’expliquions dans notre Introduction à Spring Integration, cette implémentation légère des Enterprise Integration Patterns vise à simplifier le développement de solutions d’intégration d’entreprise et à faciliter l’adoption par les utilisateurs de Spring des principes EDA (Event Driven Architecture).

  Sortie d’Hibernate Search 3.1

  La version 3.1.0 d’Hibernate Search a été mise à disposition cette semaine. Comme l’explique Emmanuel Bernard dans l’article « Hibernate Search 3.1 is out: performance, robustness and new features on the menu« , cette nouvelle version met l’accent sur l’amélioration des performances, la robustesse du code et l’utilisabilité.

  Comme nous l’expliquions dans notre Introduction à Hibernate Search, Hibernate Search est un moteur d’indexation et de recherche full-text reposant sur Apache Lucene. Il prend ainsi en charge la gestion d’un index Lucene et sa synchronisation avec une structure objet persistée en base de données.

  Agilité

  L’agilité chez IBM

  Scott Ambler, responsable du développement agile chez IBM, a été interviewé par InfoQ sur l’état présent de l’agilité et son futur.
  En se basant sur l’étude 2008 de Dr. Dobb’s, il rappelle que 69% des organisations font au moins un projet agile. L’agilité est une réalité. Le TDD fait aussi parler de lui mais ceux qui le pratiquent sont moins nombreux.

  Une autre étude a montré que les équipes agiles font autant de documentation que les équipes traditionnelles, et même plus de modélisation upfront (88% des équipes agiles), que ce soit sur papier ou avec des outils plus sophistiqués.
  Abordant les problèmes liés à l’introduction de l’Agilité dans les grandes équipes, Scott cite les 2 points les plus courants qui sont les équipes de grande taille (5000 ?) et les équipes distribuées. Il ajoute un 3e point : la gouvernance.
  L’Agilité permet une gouvernance plus efficace que les projets traditionnels, en laissant le contrôle du périmètre, du budget et de l’agenda aux intervenants (stakeholders).
  Concernant les équipes distribuées, l’étude du Dr Dobb’s rapporte le succès des projets mesuré par leurs clients :

  • équipes colocalisées : 83%
  • équipes proches (étages différents, bâtiments différents) : 72%
  • équipes distribuées (qui nécessitent l’avion) : 60%

  Scott conseille donc d’éviter les équipes distribuées. Si l’on ne peut vraiment pas, il conseille d’organiser les équipes en fonction de l’architecture afin de minimiser la communication entre les différents lieux. Cela nécessite notamment un « architecture owner », responsable de l’architecture, mais qui ne reste pas dans sa tour d’ivoire comme on peut en voir sur certains projets.

  L’autre conseil pour les équipes distribuées est de s’équiper de bons outils. Il présente le nouveau produit Rational Team Concert, basé sur Eclipse et la plateforme Jazz, qui facilite la collaboration de l’équipe.

  Pour finir avec le futur de l’agilité, Scott reprend son analogie avec l’astronomie :

  • Avant on pensait que « tout tourne autour de la Terre ». C’est la communauté traditionnelle qui pense que « tout tourne autour de l’engineering et de la documentation ».
  • Aujourd’hui la communauté agile pense que « tout tourne autour du soleil », c’est-à-dire « autour du développeur ».
  • Demain nous verrons comme Newton que « tout tourne autour de tout ». Nous devons avoir une vision entreprise et non par silo.

  Avoir une vue d’entreprise sur l’informatique est extrêmement difficile, mais nécessaire pour construire des applications de niveau entreprise et de haute qualité.

  RIA

  Au pied du sapin : JavaFX GA

  Après presque 2 ans d’attente, JavaFX est enfin disponible en version finale. Enfin pas tout à fait : JavaFX Mobile, initialement dans le scope de cette première version, est repoussé à février 2009, et les OS Linux et Solaris ne sont pas (encore) supportés.
  Cette version 1.0 tient elle malgré tout les promesses entrevues lors de la parution de la preview ?
  Et bien, pas vraiment.
  Les défauts rédhibitoires que nous y avions décelés sont toujours là : le seul IDE de développement disponible est Netbeans (sans même l’inclusion d’un éditeur graphique), les composants graphiques de haut niveau (hormis les portages Swing) manquent toujours à l’appel…
  Qu’est ce qu’apporte vraiment cette version 1.0 ? A première vue, l’effort a été porté sur la documentation : la Javadoc a été mise à jour et est relativement complète. La galerie d’exemples et de tutoriaux ‘officielle’ a été copieusement alimentée. On regrettera cependant que cette galerie mette l’accent sur le spectaculaire, plus que sur le fonctionnel (aucun exemple d’intégration avec un back end Java ou une base de données).
  Au rayon des nouveautés, on notera la présence de codecs audio et video, permettant d’intégrer facilement du contenu multimédia (par l’entremise d’un encodage en Flash).
  Sur un niveau moins technique, on peut noter la présence de 2 plugins pour les produits Adobe, Photoshop et Illustrator, qui devraient faciliter les échanges entre web designers et développeurs J2EE.
  A noter enfin, sur un plan plus marketing, la présence d’un émulateur mobile, qui préfigure ce que pourrait être JavaFx Mobile.
  En conclusion, cette première version n’est pas vraiment au niveau des attentes qu’elle a suscitées. Cependant, nous restons une fois de plus sur l’agréable impression de pouvoir faire de jolies interfaces en Java.
  A notre sens, la prochaine étape déterminante sera l’adhésion de la communauté à cette nouvelle technologie, qui devrait permettre l’émergence de composants de haut niveau (un travail auquel s’est déjà attelé James Weaver), en espérant que ceux ci seront incorporés dans les prochaines versions.
  Reste que le produit de Sun est en retard par rapport à ses concurrents, et que la volonté de couvrir toutes les plateformes à la fois (desktop, mobile, télévision) pourrait se révéler à court terme un handicap pour cette technologie émergente.
  Alors, Sun s’est il fourvoyé avec Fx, comme le pense Tim Bray ? Seules les futures versions nous le diront.

  Silverlight sous Linux

  La version 1.0 beta de Moonlight est disponible.
  Moonlight est une implémentation open source de Silverlight pour Linux / Unix, portée par Novell et développée par le projet Mono. Cette béta est disponible pour un grand nombre d’environnements (Ubuntu, Suze, Fedora…) en 32 ou 64 bits.
  Elle permet l’exécution de scripts Silverlight 1.0, la diffusion de contenu (MediaPack 1.0)…
  Elle sera disponible en version finale le 20 janvier 2009.
  Pour pouvoir profiter au maximum de Silverlight sous Linux, il faudra attendre la version 2 de Moonlight (support complet de Silverlight 2.0 et des dernières innovations Microsoft). Elle devrait être disponible en béta courant avril, puis en finale durant septembre 2009.
  La roadmap complète est exposée sur le site du projet Mono.

  Le coin de la technique

  Nouveau mode hosté pour GWT 2.0

  Les nouveautés des prochaines versions 1.6 et 2.0 de GWT continuent d’affluer.
  Ainsi, après la possibilité de pouvoir fragmenter son application, c’est une fois de plus chez Sami Jaber que l’on apprend en vidéo l’une des grosses fonctionnalités à venir : le nouveau « Hosted Mode » de GWT 2.0.
  Alors qu’aujourd’hui ce mode se lance dans une nouvelle fenêtre de votre IDE, demain vous pourrez le lancer directement dans votre navigateur (en tout cas ceux gérés pour l’instant).
  Le mode reste toutefois celui que l’on connaît à savoir que GWT simule un site compilé (moteur de rendu) i.e. qu’aucun Javascript n’est généré. L’intégration avec des plugins comme Firebug sera donc limitée… Le mode Debug et le rafraichissement du navigateur suite à modification du code GWT sont bien sûr conservés.

  ]]> http://blog.xebia.fr/2008/12/08/revue-de-presse-xebia-86/feed/ 3 http://blog.xebia.fr/2008/11/17/revue-de-presse-xebia-83/ http://blog.xebia.fr/2008/11/17/revue-de-presse-xebia-83/#comments Mon, 17 Nov 2008 18:04:04 +0000 Xebia France http://blog.xebia.fr/?p=997
  La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

  Actualité éditeurs / SSII

  • Sun supprime 5.000 à 6.000 emplois dans la continuité de sa mutation en un acteur Open Source
  • SpringSource dévoile sa roadmap

  RIA

  • Le framework préféré des développeurs Flex
  • Adobe lance Cocomo

  Le coin de la technique

  • Essayez le nouvel algorithme Garbage First
  • Gestion des documents Office 2007
  • Hyperic v4.0 : le monitoring d’applications Java passe par JMX
  • Sortie de Grails 1.0.4

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

  • Open Source eXchange : comptes-rendus des participants
  • L’Aquarium à Paris le 12 décembre : inscriptions ouvertes

  Actualité éditeurs / SSII

  Sun supprime 5.000 à 6.000 emplois dans la continuité de sa mutation en un acteur Open Source

  Sun annonce un plan de restructuration assez conséquent puisqu’il touchera plus de 15% de ses effectifs.

  Triste nouvelle. La nécessaire mutation de ce fleuron de l’informatique des années 90, tiraillé entre son activité hardware en déclin (traditionnellement haut de gamme, mais malheureusement à contre-courant d’investissements en berne en période de crise) et son activité software (en recherche d’un second souffle – le patron de la branche logicielle, Steve Green est parti Vendredi dernier), est en marche depuis plusieurs années et n’est pas une surprise.

  L’annonce faite sur le site Corporate de Sun est claire : Software et Open Source !
  Espérons pour Sun que les récentes (pour certaines judicieuses) et coûteuses acquisitions porteront leurs fruits.

  Si nous osions, nous dirions que, toute activité hardware mise à part, Sun ressemble de plus en plus à des pures players de l’Open Source au même titre que Redhat par exemple.

  Il n’est en effet pas surprenant que Sun ait choisi cette voie. Lors de la conférence de Malaga des partenaires de Redhat, à laquelle Xebia était invitée, James Whitehust nous époustouflait en nous annonçant que sa marge et sa croissance étaient parmi les plus élevées de l’industrie logicielle (information vérifiée et qui s’avère exacte).

  Bonne continuation à Sun dans cette voie, elle est légitime. Et bonne chance avec la prometteuse gamme Sun Storage 7000, un condensé de hardware, d’open source et d’innovation dans le lignée du nouveau modèle Sun !

  SpringSource dévoile sa roadmap

  Vous avez probablement entendu parler des rencontres Spring qui se sont déroulées jeudi dernier. Nous ne résumerons pas ici le contenu de l’ensemble des conférences, d’autres blogs s’en sont déjà chargés avec brio (cf liens annexes). Si, dans l’ensemble, les conférences étaient plutôt réussies, nous avouons être un peu restés sur notre faim :

  • Les discussions ont beaucoup tourné autour du rachat par SpringSource de G2One sans pour autant révéler clairement la place de Groovy et Grails dans la stack Spring. Elles ont tout de même permis de servir de point de départ à des discussions off bien plus intéressantes lors de la pause.
  • Aucune explication sur les (petits) retards de la M1 de Spring 3.0, aucune référence à Spring JavaConfig ni à l’intégration des Servlet 3.0, pas de communication sur le contenu des M2 et M3, bref, rien de neuf depuis le billet que nous avons publié le mois dernier sur Spring 3.0.

  Heureusement donc que ce rachat, annoncé en début de semaine, et la présence de speakers d’exceptions ont permis de pimenter cette demi-journée.

  La partie la plus intéressante a été probablement celle de Peter Cooper Ellis nous présentant de la roadmap Spring dont voici les points à retenir :

  • Concernant Spring 3.0 : le premier milestone doit sortir d’ici fin novembre. Il sera probablement suivi d’un M2 et d’un M3 avant l’arrivée d’une Release Candidate prévue en mars 2009. La sortie officielle devrait arriver en avril si tout se passe bien.
  • Sortie de Spring Integration d’ici la fin de l’année.
  • La version 1.2 de Spring DM devrait sortir durant le premier trimestre 2009 offrant le support au Configuration Admin service. Elle sera suivie peu de temps après par la version 2.0 qui implémentera l’OSGi Blueprint Service (RFC 124) partie d’OSGi R4.2. Spring DM 2.0 sera d’ailleurs probablement la reference implementation de ces spécifications. Sa date de sortie est prévue pour le second trimestre 2009.
  • En parallèle à cela, deux nouvelles versions de Spring dmServer sont planifiées l’année prochaine. La première, dmServer Jersey, offrira, entre autres, une compatibilité Tomcat. Cette version devrait voir le jour au second trimestre 2009. L’autre version est prévue pour fin 2009 : dmServer Ockney. En voici quelques nouveautés : load balancer dynamique, enregistrement et exécution de scripts sur la console …
  • Notons également au premier trimestre 2009 : une mise à jour de Spring IDE (2.5) et les versions 1.6 de Groovy et 1.1 de Grails, dont Guillaume Laforge vente les mérites depuis la soirée Groovy du Paris JUG.
  • Mais c’est le second trimestre qui sera le plus chargé avec au programme : Spring Batch 2.0, Spring Security 2.5, Spring ROO et Spring Web. La version 2.0 de Spring Batch apportera une mise à jour importante de ce framework : passage à Java 5, configuration via annotations, on parle également d’une éventuelle intégration avec la stack apportée par G2One. Vous aurez également remarqué la présence d’un nouveau framework baptisé Spring ROO. Il s’agirait d’un framework RAD / DDD de génération de codes privilégiant les conventions à la configuration (tiens, tiens, ça nous rappelle quelque chose). Ici encore, aucune information n’est donnée quant à la place de ce framework vis-à-vis de Grails.
  

  Notez que ce planning ne se veut ni complet ni définitif, certaines de ces dates seront très probablement amenées à évoluer.

  Liens connexes :

  • Consultez l’agenda de la demi-journée.
  • Téléchargez-les slides des conférences.
  • Remerciements post-conférences par Julien Dubois.
  • Résumé de la demi-journée par Pierre Mage.
  • Résumé de la demi-journée par Olivier Mallassi.
  • Résumé de la demi-journée par Nicolas Martignole.
  • Autres billets : Spring dmServer, le pari fou ?, Tuning Tomcat par Thomas Queste.

  RIA

  Le framework préféré des développeurs Flex

  Rich Tetrola a lancé la semaine dernière un sondage sur le framework préféré des développeurs Flex. Et voici le résultat. PureMVC remporte le sondage à la surprise de l’auteur lui-même qui misait plutôt sur Cairngorm. Les candidats au titre de framework préféré des développeurs Flex étaient :

  • Cairngorm : une micro architecture fournissant plusieurs motifs de conception (notamment le Modèle-Vue-Contrôleur).
  • PureMVC : un framework permettant de concevoir des applications basées sur le motif de conception Modèle-Vue-Contrôleur.
  • Mate : un framework qui gère les évènements dont voici une démonstration Hello World.
  • Swiz : un framework facilitant le développement d’applications riches.
  • EasyMVC : il permet également de concevoir des applications sur le motif de conception Modèle-Vue-Contrôleur.
  • Ruboss : il facilite le développement d’application Flex/Rails.

  Cairngorm, bien qu’il soit un produit d’Adobe Labs, n’a pas remporté le succès attendu à cause de sa complexité, c’est ce qui ressort des commentaires. Peut être est ce à cause de son « ModelLocator fourre tout ». Les résultats sont intéressants mais il ne faut pas les prendre au pied de la lettre. Tous ces frameworks ont pour but de mettre en place de bonnes pratiques dans le développement d’applications riches. Chacun dispose d’avantages et d’inconvénients à bien évaluer lorsqu’on veut choisir d’utiliser l’un de ces frameworks.

  Adobe lance Cocomo

  Avec cette première version bêta dans les labs, Adobe étoffe encore son offre RIA.
  Cocomo est une plateforme Flex permettant au développeur d’ajouter des capacités « sociales » aux applications RIA. Cocomo mêle une partie cliente Flex et les infrastructures réseau mises à disposition par Adobe. En bref, il permet de facilement mettre en place des outils collaboratifs dans vos applications Flex. La version bêta propose déjà le support de :

  • Conférences audio (par VoIP).
  • Conférences vidéo (par Webcam).
  • Chat texte.
  • Echange de fichiers.
  • Gestion des utilisateurs.
  • Et d’autres choses à découvrir.

  Pour plus d’informations rendez vous sur le site d’Adobe : Présentation de Cocomo.

  Le coin de la technique

  Essayez le nouvel algorithme Garbage First

  Danny Coward, dont nous avons déjà parlé à plusieurs reprises, a publié cette semaine sur son blog un billet annonçant la disponibilité du nouvel algorithme pour le ramasse-miettes Java sur le dernier build du JDK 7 (bon courage pour l’installer …). Trois saisons ont passé depuis la publication sur notre blog d’un article présentant le fonctionnement de celui-ci. Son principe n’a pas changé, vous pouvez donc toujours vous y référer si le sujet vous intéresse : GC générationnels traditionnels (JDK 6) VS Garbage First (JDK 7).

  À retenir sur ce nouvel algorithme, Garbage First (G1) :

  • Il est destiné à remplacer le parrallel and concurrent mark and sweep.
  • Il devrait être activé par défaut dès le JDK 7.
  • Il propose un nouveau découpage du tas : la taille des zones mémoire se réduit, plus de zones sont créées en contrepartie.
  • Il permet également d’exploiter les forces des architectures multicœurs.
  • Il se veut plus prédictible et moins intrusif en offrant par exemple des garanties sur des temps de pauses.
  • Il permet en moyenne d’obtenir un meilleur débit de nettoyage, tout en offrant une implémentation simple à comprendre.

  Gestion des documents Office 2007

  La société Aspose annonce la sortie d’une nouvelle version de son produit Aspose.Word permettant de gérer nos fichiers Word 2007, les fameux .docx de Microsoft Office 2007 (annonce relayée par The Server Side).

  Cette 2.6.0 ajoute l’importante fonctionnalité de pouvoir charger un fichier Word existant, rendant possible l’édition de celui-ci. Un produit très complet donc, qui gère aussi les images, les zones de texte, les objets OLE et Active X et bien d’autres fonctionnalités de Microsoft Word.

  A noter que la gestion des fichiers Excel 2007 (.xlsx) et PowerPoint 2007 (.pptx) est en très bonne voie chez Apache POI, le support du format OOXML étant déjà disponible dans POI en version 3.5 beta 3. Ce support est désormais une priorité pour le projet. Rappelons que depuis quelques mois Microsoft est partenaire du projet Apache POI et contribue ainsi à l’intégration de son format dans POI.

  Hyperic v4.0 : le monitoring d’applications Java passe par JMX

  Hyperic HQ, l’outil de supervision choisi par Iona (Fuse HQ), Redhat (JBoss Operations Network) et SpringSource (Application Management Suite), dévoile cette semaine sa version 4.0 dont une des nouveautés clefs est le nouveau JMX MBean Browser.

  Nous retiendrons de cette annonce que JMX est la technologie incontournable pour superviser des applications Java. Le développement d’indicateurs en MBean JMX est aujourd’hui très facile pour les équipes applicatives avec des frameworks comme Spring JMX et la consultation de ces informations est banalisée avec l’incontournable Visual VM (cf Blog Xebia : Diagnostique d’une JVM à distance).

  Ne pas s’intégrer facilement à JMX est aujourd’hui un très sévère handicap pour une solution de supervision d’applications Java.

  Sortie de Grails 1.0.4

  La sortie officielle de Grails 1.0.4 vient d’être annoncée par SpringSource. Pour ceux qui ne le connaissent pas, Grails est un framework orienté web écrit en Java et Groovy et placé sous licence Apache. Il s’inspire fortement du framework Rails (Ruby on Rails). Mais contrairement à Rails, Grails est ancré complètement dans l’univers Java, et repose sur des frameworks très connus comme Spring ou Hibernate.

  Cette nouvelle version propose des nouvelles fonctionnalités pour une meilleure intégration avec Spring et Hibernate, un support des tags JSP dans GSP, de nouveaux plugins pour Java Content Repository (JCR API), Java Persistence API (JPA) et l’api Portlet.

  L’année prochaine s’annonce très prometteuse, avec la possibilité d’intégration de Groovy avec Grails et des produits du portefeuille Spring comme Spring Batch, Spring Integration, et Spring dm Server.

  Autres liens :

  • Le site officiel de Grails.
  • La documentation officielle : http://grails.org/doc/1.0.4.

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

  Open Source eXchange : comptes-rendus des participants

  Si vous n’avez pas pu assister à la journée OpenSource Exchange organisée conjointement par Skills Matter et Xebia de la semaine dernière, nous vous proposons ici en rattrapage quelques-uns des retours effectués par les participants à cette journée.

  • Éric Lefevre met à disposition sur son blog un compte rendu synthétisant l’ensemble de la journée.
  • Olivier Croisier a quant à lui effectué une série d’articles fort intéressante sur chacune des conférences :
  • Compte rendu SpringSource dmServer, dont la conférence était présentée par Michael Isvy.
  • Compte rendu eXo Platform, dont la conférence était présentée par Tugdal Grall.
  • Compte rendu Java EE 6, dont la conférence était présentée par Antonio Goncalves.
  • Compte rendu Groovy, dont la conférence était présentée par Guillaume Laforge.
  • Compte rendu Glassfish v3, dont la conférence était présentée par Alexis Moussine-Pouchkine.
  • Compte rendu Portlet 2.0, dont la conférence était présentée par Christophe Laprun.
  • Compte rendu Hadoop, dont la conférence était présentée par Hugues Le Bars.

  Nous profitons de cette revue de presse pour les remercier.

  Vous pouvez également nous proposer d’autres comptes-rendus si vous le désirez.

  L’Aquarium à Paris le 12 décembre : inscriptions ouvertes

  Nous en parlions la semaine dernière, Sun organise le vendredi 12 décembre une journée gratuite « GlassFish et Java » dans ses locaux au 42, avenue d’Iéna à Paris.
  Cette journée a été baptisée « L’Aquarium à Paris » et sera l’occasion de couvrir un large spectre de la gamme Sun :

  • GlassFish,
  • Java EE 6,
  • Grizzly Comet,
  • Jersey,
  • OpenMQ,
  • JavaFX,
  • MySQL,
  • OpenSSO,
  • OpenESB.

  Parmi les intervenants: Roberto Chinnici (spec lead), Richard Bair (tech lead), Paul Sandoz (spec lead), Linda Schneider (tech lead), Jean-François Arcand (tech lead), etc…

  Les inscriptions sont désormais ouvertes.

  ]]> http://blog.xebia.fr/2008/11/17/revue-de-presse-xebia-83/feed/ 1 http://blog.xebia.fr/2008/11/14/conference-open-source-exchange-un-grand-merci-et-a-lannee-prochaine-si-vous-le-voulez-bien/ http://blog.xebia.fr/2008/11/14/conference-open-source-exchange-un-grand-merci-et-a-lannee-prochaine-si-vous-le-voulez-bien/#comments Fri, 14 Nov 2008 13:21:25 +0000 Xebia France http://blog.xebia.fr/?p=992 La conférence Open Source eXchange que Xebia et Skills Matter ont conjointement organisé cette semaine en guise d’inauguration de leur partenariat a été une très bonne première édition.
  Nous remercions tout particulièrement les intervenants à savoir :
  • Michael Isvy.
  • Tugdual Grall.
  • Antionio Goncalves.
  • Guillaume Laforge (dans le cœur de l’actualité SpringSource).
  • Alexis Moussine-Pouchkine.
  • Christophe Laprun.
  • Hugues Le Bars.

  Le Vidcast de la conférence sera bientôt disponible sur notre blog ainsi que sur le site de Skills Matter.

  Nous souhaitons bien entendu reconduire cet évènement l’année prochaine.

  Xebia et Skills Matter

  ]]> http://blog.xebia.fr/2008/11/14/conference-open-source-exchange-un-grand-merci-et-a-lannee-prochaine-si-vous-le-voulez-bien/feed/ 2