Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Sun étend son IDE Netbeans

Agilité

• Scrum : les raisons d’un échec

Le coin de la technique

• Les dangers de l’autoboxing
• VisualVM dans le JDK
• Nouvelle arme pour la concurrence : le CyclicBarrier générationnel
• Diagramme d’activité des codes retour HTTP
• EclipseLink 1.0 released : un concurrent sérieux à Hibernate ?
• Protocol Buffers, la solution de Google pour gérer la sérialisation de structure de données

Actualité éditeurs / SSII

Sun étend son IDE Netbeans

Netbeans, l’IDE de Sun, étend son outil de développement sur deux axes :

• Le développement PHP
• Le développement Python

La stratégie de Netbeans est de fournir une alternative au champion actuel : Eclipse.
Le challenger Netbeans, se distingue d’Eclipse en fournissant par défaut un outil de développement multi technologies :

• Java SE, Java EE & Web (XML, HTML, Javascript, JSP, JSF), Java ME, UML, Ruby, C/C++, PHP (actuellement en milestone1), python (dans un futur proche)
• Intégration de Glassfish le serveur d’application Sun, et d’Apache Tomcat

Etant donnée l’hétérogénéité des technologies mise en œuvre pour la réalisation d’une application de gestion (Web, Middleware, …), la stratégie de Netbeans est intéressante.

Google Trends : Netbeans vs Eclipse, Netbeans de plus en plus populaire

Agilité

Scrum : les raisons d’un échec

Nous parlons souvent sur ce blog des succès que nous rencontrons dans la mise en œuvre de la méthode Scrum.
Robin Dymond a connu l’échec sur un projet Scrum, et revient courageusement sur les causes de ce raté : A scrum project that failed
Dans le cas de Robin, les 2 principales raisons d’insuccès ont été :

• L’entité métier à qui était destiné le produit n’était pas à l’origine du projet : c’est la direction IT et la direction des Opérations qui l’ont poussée.
• Le choix d’un progiciel a été fait en amont du projet, avant même que l’équipe technique ou que les utilisateurs finaux ne le testent.

En commentaire au billet de Robin, Elizabeth Hendrickson souligne un point essentiel à nos yeux : dès l’itération 3, l’équipe savait que le progiciel ne répondrait pas aux besoins métier. Personne n’a réagit à ces signaux avant-coureurs d’échec. Or, l’une des grandes forces des méthodes agiles est le ‘feedback’ rapide. Ignorer ces signes c’est se mettre volontairement dans une situation délicate.

Ce billet est à l’origine d’un fil de discussion tentant de cataloguer les mauvaises pratiques Scrum : riche d’enseignements.

Le coin de la technique

Les dangers de l’autoboxing

Dans la lignée des revues de presse précédentes ou nous avions parlé des bonnes utilisations des enum et des generics, un article publié sur Dzone nous donne l’occasion de rappeler quelques bonnes pratiques sur l’autoboxing.

Si l’autoboxing réduit la verbosité, elle n’écarte pas les dangers liés aux mauvaises utilisations des classes wrappées, pire, elle en rajoute. Par exemple, lorsqu’un programme unboxe une variable, un NullPointerException peut être lancé si celle-ci est null.

Quelques points à retenir :

• Il n’est jamais bon d’utiliser == sur des objets autres que des primitives même si quelquefois les comparaisons sont correctes (cf exemple ci-dessous)
• Quand vous mixez des primitives avec des primitives boxées dans une même opération, la variable wrappée est automatiquement unboxée.
• Ne jamais utiliser l’autoboxing dans un contexte synchronisé

// opérations mixtes : les types wrappés sont unboxés
System.err.println(Integer.valueOf(42) == 42); // true
System.err.println(Integer.valueOf(42) == 42L); // true
System.err.println(new Integer(42) == 42); // true
System.err.println(new Long(42) == 42); // true

// création d'un nouvel objet : '==' ne fonctionne pas
System.err.println(Integer.valueOf(42) == new Integer(42)); // false

// utilisation dangereuse du '=='
// fonctionne sur entiers < 128 seulement
System.err.println(Integer.valueOf(42) == Integer.valueOf(42)); // true
System.err.println(Integer.valueOf(4242) == Integer.valueOf(4242)); // false !!

// Lance un NullPointerException
final Integer i = null;
System.err.println(i == 42); // NPE !!

Consulter l'article : "Why I'm Not a Fan Of Java's Auto-Unboxing"

VisualVM dans le JDK

Sun vient de sortir une nouvelle version de Java : jdk 6 update 7 . Outre les différentes corrections d'anomalies, la principale nouveauté de cette version est l'intégration de VisualVM au sein des outils du jdk.

VisualVM fournit et agrège des données détaillées sur le comportement d'une application Java en cours d'exécution via les informations recueillies par la machine virtuelle. La majorité de données y sont présentées de manière graphique. Il vous est également relativement aisé de créer vos propres plugins, cela fera certainement l'objet d'un prochain article dans notre blog. Notez au passage qu'il vous est possible d'utiliser celui-ci sur les versions antérieures du jdk (jusqu'à la version 1.4.2), mais quelques fonctionnalités ne seront pas disponibles.

Nouvelle arme pour la concurrence : le CyclicBarrier générationnel

Doug Lea, spec lead de la JSR-166 (concurrency utilities), présente une nouvelle fonctionnalité du package java.util.concurrent qui sera ajoutée lors de l'arrivée du jdk 7 : le Phaser. Son fonctionnement est comparable au Cyclic Barrier, qui permettait depuis le jdk 5 de faire attendre un groupe de threads pour leur faire atteindre un but commun simultanément, mais se veut plus flexible, plus performant et plus scalable que son prédécesseur.

• Il permet l'ajout et la suppression dynamique de threads participant à la barrière
• Il permet de gérer des générations (ou phases, d'où son nom) : à chaque fois qu'une barrière est atteinte, une variable est incrémentée.
• Il peut être éteint à chaud, en forçant l'appel à une action ou non (facilite la reprise sur erreur)
• Il est compatible avec la nouvelle API de fork and join

Diagramme d'activité des codes retour HTTP

Contrairement à ce que certains pourraient penser (non, pas la peine d'insister, on ne vous communiquera pas les noms), il n'y pas que les erreurs 404 et 500 dans la vie. En voici la preuve ! Alan Dean a regroupé, sur un même diagramme d'activité, les différents codes de retour qu'il est possible d'obtenir dans une réponse HTTP.

• Diagramme d'activité des status codes http
• D'autres formats sont disponibles sur la page originelle
• Consultez la RCF 2616 : HTTP/1.1

EclipseLink 1.0 released : un concurrent sérieux à Hibernate ?

La version 1.0 d'Eclipse Link est disponible en téléchargement. Cette release sonne le glas de l'outil persistance d'Oracle (TopLink) légué au monde open source au profit de la fondation Eclipse en mars dernier. Avec cette version, le projet sort également de l'incubateur Eclipse pour devenir un top-level project.

• Implémente JPA 1.0 et offre des fonctionnalités spécifiques. A terme, EclipseLink devrait devenir l'implémentation de référence pour JPA 2.0
• Implémente SDO 2.1
• Object-XML binding via JAXB (MOXy)
• Disponible en bundles OSGI

Protocol Buffers, la solution de Google pour gérer la sérialisation de structure de données

Le Journal Du Net a annoncé que Google souhaite offrir une alternative à XML.

Pour gérer l'échange de données d'une application à une autre (avec des langages d'implémentation différents), le format XML s'impose de raison pour structurer les messages échangés. Après avoir défini une structure pivot pour l'échange de message, chaque application implémente un parseur afin de sérialiser et desérialiser les messages entrants et sortants.

Google met donc à disposition Protocol Buffers, qu'ils utilisent en interne (ils ont plusieurs milliers (12 183) de descripteurs .proto dans leur base de code), en fournissant une alternative plus performante et plus simple que la sérialisation XML. Comme le XML, Protocol Buffers a pour ambition d'être portable d'une plateforme à une autre, et d'un langage à un autre (aujourd'hui les langages supportés sont C++, Java et Python).

Protocol Buffers fonctionne de la manière suivante :

• On réalise un fichier de grammaire .proto
• On génère la structure de données à partir de ce fichier de grammaire, dans le langage de destination souhaitée : C++, Java ou Python
• On génère le parser à partir de ce fichier de grammaire, dans le langage de destination souhaitée : C++, Java ou Python

Tutorial Java pour l'utilisation de Protocol Buffers

Le mécanisme est légèrement différent d'une solution basée sur XML. En effet, en XML, il n'y a pas la deuxième étape : la génération de la structure de données. Cela permet à Protocol Buffers d'avoir des messages plus petits qu'un fichier XML (en terme de taille en octets). Cependant, les messages sont moins lisibles pour l'homme, mais un outil est mis à disposition pour pallier à ce frein (si c'est un frein).

Les objectifs affichés de Google avec Protocol Buffers sont d'avoir une solution de sérialisation/desérialisation de message :

• 20 à 100 fois plus rapide qu'avec des fichiers XML
• Avoir du code plus simple et plus facile à maintenir que des solutions autour d'XML (parser XML, ...)
• Il est possible de mettre à jour la structure de données sans casser les applications qui ont été compilées sur une version plus ancienne

Site officiel de Protocol Buffers
Annonce sur le blog Google Open Source