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

Actualité éditeurs / SSIIest

• Ehcache Search
• Chez Oracle: Netbeans 7, Java FX 2…

Agilité

• Continuous Delivery selon Martin Fowler et Jez Humble

Le coin de la technique

• jBPM 5 est de sortie
• Google Web Toolkit 2.2

Actualité éditeurs / SSII

Ehcache Search

La nouvelle version Ehcache 2.4 est sortie la semaine dernière, elle apporte une nouvelle fonctionnalité importante, Search, qui améliore les mécanismes de recherche. Elle offre entre autre une API fluent (Désignation chainée en français ?) qu’on retrouve souvent dans les API de recherche de ce type. Voici un exemple:

Results results = cache.createQuery().includeKeys().addCriteria(age.eq(32).and(gender.eq(“male”))).execute();

Nous voici donc avec un nouveau query language, EQL, qui rassemble toutes les fonctionnalités classiques de requêtage: les critères ( eq , lt, like, ilike, between…), les tris descendant/ascendant et les agrégateurs ( min , max, avg, sum, count…). Par contre il n’y a pas de possibilités de jointure.

Deux approches ont été utilisées selon qu’on soit en mode standalone ou distribué. En standalone la recherche se fait simplement en parcourant l’ensemble des éléments. Même si il y a beaucoup d’éléments le fait d’être en local permet d’avoir un temps de réponse très bon (d’après Ehcache, 1 million d’entrée en moins d’une seconde environ). Par contre le mode distribué, qui ne sera disponible qu’avec la future release Terracota 3.5, s’appuie sur des indexes et est par conséquent beaucoup plus rapide sur des tailles de cache de plusieurs giga voire téra octets. Dans ce mode on peut doubler le volume en gardant quasiment le même temps de réponse si on ajoute tout simplement un cache. A noter que la mise à jour des indexes est asynchrone.

Sans être révolutionnaire voici une nouvelle fonctionnalité assez utile pour un outil déjà appréciable par sa simplicité.

Chez Oracle: Netbeans 7, Java FX 2…

Attention, cette info est réservée à un public averti. Aux aventuriers du code. A ceux qui aiment prendre des risques avec leurs sources en utilisant un IDE encore en bêta. En effet, la bêta 2 de Netbeans 7 vient de sortir. Et elle sait nous mettre l’eau à la bouche ! On ne sera pas surpris d’apprendre que le support des produits Oracle comme WebLogic ou la base de donnée a été amélioré, mais c’est surtout le support de Java 7 qui nous fait saliver: découvrez les possibilités de refactoring dans les release notes.
Toujours concernant Netbeans, certains d’entre nous avaient été déçus de l’annonce de l’arrêt du développement du plugin Ruby. Rassurez-vous, la newsletter hebdomadaire de Netbeans annonce que Tom Enebo et la communauté comptent continuer à le développer. C’est une bonne nouvelle pour les amateurs de multilinguisme.

Pour continuer sur Oracle, Gerbrand van Dieijen, notre collègue Xebian néerlandais, nous livre quelques informations glanées lors d’un JUG. Les voici:

• comme prévu, le langage de script JavaFX est bien abandonné. Java FX 2 sera une librairie jar.
• il sera possible de mixer Swing et JavaFX2…
• … mais Swing est en mode maintenance. Comprendre « ne plus attendre d’innovations de ce coté ». Aie…

Faut-il s’attendre à ce que Java FX2 soit en fait Swing 2 ? Nous verrons mais en attendant, contrairement à d’autres, nous avons du mal à nous enthousiasmer pour un simple composant TableView qui était absent de la librairie jusqu’ici (bien que gérer correctement une table soit beaucoup plus dur qu’il n’y parait !).

Agilité

Continuous Delivery selon Martin Fowler et Jez Humble

Martin Fowler et Jez Humble (product manager de Go chez ThoughtWorks) ont présenté à QCon 2010 leur vision du Continuous Delivery. Nous retiendrons :

Qu’est ce que le « Continuous Delivery »

L’objectif du « Continuous Delivery » est d’accélérer le rythme de release des logiciels. L’Agilité et le « Continuous Integration » ont traité les périmètres des équipes fonctionnelles et de développement ; « Continuous Delivery » prolonge cette dynamique aux équipes de production.

Les bénéfices majeurs sont :

• Valider plus rapidement le « business plan » en recueillant plus rapidement les retours d’expérience des utilisateurs,
• Réduire les risques de mise en production (et donc des coûts) par rapport aux approches « Big Bang » grâce à des incréments plus petits, plus fréquents et automatisés.

Pour atteindre cet objectif, « Continuous Delivery » propose d’automatiser les phases de « build-deploy-test-release » en un « Build Pipeline ». Cela comporte l’automatisation de tests intégrés (User Acceptance Tests, Performance Tests, etc), la gestion des configurations, des environnements et des données ainsi que l’automatisation des déploiements.

Plus de détails dans InformIT – Continuous Delivery: The Value Proposition.

« Continuous Delivery » versus « Continuous Deployment »

« Continuous Delivery » et « Continuous Deployment » diffèrent par le fait que « Continous Delivery » laisse au business le choix du rythme des releases. Le logiciel doit toujours être releasable mais c’est le business qui choisit la date de la release (e.g. un éditeur limite le nombre de release à supporter, les équipes ne sont pas forcément disponibles pour supporter une mise en production, etc). A l’inverse, « Continuous Deployment » promeut la mise en production permanente ; chaque commit est l’occasion d’une release, il s’agit de « continuous release ».

Plus de détails dans Jez Humble – Continuous Delivery vs Continuous Deployment.

Les enjeux et pièges de l’adoption du « Continuous Delivery »

Le principal enjeu du « Continuous Delivery » est culturel : il s’agit de faire travailler ensemble les équipes de développement, de validation (QA) et d’exploitation.

Le premier piège de l’adoption de « Continuous Deployment » est le même que pour l’adoption de l’Agilité : l’adoption en mode « Big Bang ». Il faut à la place procéder incrémentalement, automatiser les étapes une par une en identifiant à chaque fois l’action la plus bénéfique.

« Continuous Delivery », « Feature Branching » et « Feature Toggle Pattern »

Martin Fowler et Jez Humble recommandent le développement sur le ‘trunk’ plutôt qu’une approche de « feature branching » à cause des difficultés de merge.

Tant qu’une fonctionnalité n’est pas complètement « done » ou que le business n’a pas décidé de son activation définitive, on recourra à un pattern de « feature toggle » qui permet d’activer/désactiver par configuration la fonctionnalité. Cette approche permet notamment le canary releasing et le A/B testing.

Plus de détails sur Martin Fowler’s Bliki : Feature Toggle.

Les outils pour le « Continous Delivery »

Il y a peu d’outils à part Go de Toughtworks. Les serveurs d’intégration continue commencent à s’intéresser au sujet (cf Atlassian Bamboo 3). Les produits Open Source comme Maven ou Hudson n’ont pas de proposition pour le moment.

Le coin de la technique

jBPM 5 est de sortie

La version 5 de jBPM est sortie il y a peu de temps. Pour mémoire, jBPM est une librairie open-source faite par JBoss pour faire du BPM (Business Process Management). On se rappellera que le projet a connu quelques heurts dont le départ de ses 2 principaux membres: Tom Baeyens et Joram Barrez avaient abandonné le navire pour aller faire Activiti sous la houlette de Alfresco. La 1ere version d’Activiti est d’ailleurs sortie récemment, avec le numéro de version 5, sans doutes pour concurrencer jBPM 5 !

Tout comme Activiti, ce jBPM 5 voit la généralisation du langage BPMN 2 pour décrire les process. Et par conséquence l’abandon du langage propriétaire JPDL employé jusqu’alors en parallèle de BPMN 1.2.
JBPM 5 résulte d’un merge avec Drools Flow et sort accompagné entre autres de plugin Eclipse, d’une console web de management et d’un Process Repository avec Guvnor.

JBPM 3, lui, a joui et jouira pour encore quelques années d’un support complet de la part de jBoss. De plus, des outils sont prévus pour migrer les process vers jBPM 5. Ce sont les utilisateurs de jBPM 4 qui se retrouvent le bec dans l’eau: il semble que rien n’est prévu pour eux. Toutefois il est vrai que cette version n’a jamais été présentée comme étant officiellement supportée, mais plutôt community. Notons tout de même que, comme indiqué en fin de cet article, ce sont les process qui seront migrés, et non les données de ces process.

L’intégration avec Drools sera-t-elle un pari réussi pour JBoss ? En tout cas le projet semble n’avoir pas trop souffert du départ de ses leaders et le combat pour le titre de solution BPM Open Source ne fait que s’engager avec Activiti. Profitons en pour noter que les français de Bonitasoft proposent eux aussi une solution concurrente.

Google Web Toolkit 2.2

La version 2.2 du framework GWT est sortie la semaine passée. Cette sortie, en plus d’un lot de correctifs, s’accompagne d’une mise à jour des outils de développement.

Le plugin GPE (Google Plugin for Eclipse) intègre donc en standard une version light de GWT Designer. GWT Designer est un outil WYSIWYG pour la création d’interfaces GWT. La version allégée n’inclut pas le support des librairies GWT-Ext, GXT ou SmartGWT. Elle offre moins d’options de configuration, et n’inclut pas les assistants et vérificateurs de la version complète pour s’appuyer sur ceux de GPE. La version complète reste toujours disponible gratuitement.

Autre nouveauté, le framework inclut un support expérimentale pour les éléments HTML 5 Canvas, Video et Audio. Les API sont encore susceptibles d’évoluer, mais l’équipe de développement pense qu’elles sont suffisamment « stables » pour être publiées. Et une démo et son code source sont accessibles ici.

On notera également l’ajout des fonctionnalités de tri et de dimensionnement des colonnes sur le composant CellTable.

Enfin, cette version déprécie le support de Java 1.5. Noter que l’équipe s’engage à supporter Java 1.5 au moins jusqu’à la prochaine release. Toutefois, la migration vers une version plus récente du runtime est recommandé.