Revue de Presse Xebia

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

Actualité éditeurs / SSII

Le coin de la technique

Actualité éditeurs / SSII

JBoss SOA Platform : série d’annonces à JBossWorld

JBoss Black Tie
L’annonce la plus importante aux yeux de l’éditeur. Black Tie est un middleware open source qui étend JBoss Transactions aux applications C / C++ et Mainframe pour les intégrer aux applications Java. Black Tie est destiné à transformer la plateforme JBoss en environnement transactionnel haute performance et à concurrencer directement le moniteur transactionnel BEA Tuxedo dont il supportera les APIs.
Le projet est très ambitieux, Marc Fleury est enthousiaste et les médias IT sont déjà à l’affût (IT World – Red Hat’s JBoss dons Black Tie to target BEA Tuxedo, InformationWeek – Red Hat Adds Black Tie As Substitute For Tuxedo, etc).

Alliance RedHat/Hyperic autour du projet RHQ
RedHat utilisait déjà la plateforme Hyperic HQ pour ses consoles de supervision payantes RedHat Network et JBoss Operations Network. Les deux éditeurs s’allient aujourd’hui autour du projet open source RHQ pour développer conjointement les modules de monitoring et d’administration de l’ensemble de la stack RedHat/JBoss (RHEL, JBossAS, Hibernate, etc).
On y voit ici un changement de politique de monétisation des consoles de monitoring qui étaient autrefois réservées aux clients de souscriptions et que RedHat/Jboss rend désormais accessibles gratuitement.
Cette démarche coupe l’herbe sous le pied d’autres acteurs open source comme Spring, Iona ou Mule qui ont récemment annoncé des partenariats avec le même Hyperic pour proposer des consoles d’administration toujours réservées aux clients de souscriptions (Spring HQ, Iona Fuse HQ et Mule-HQ).
C’est par ailleurs une belle opération pour Hyperic qui réaffirme sa position de leader de la supervision des stacks open source. Il ne reste plus qu’à transformer cette médiatisation et les qualités du produit en parts de marché.
Nous souhaitons à Hyperic que la récente annonce de CNET augure d’autres bonnes nouvelles (CNET Networks Selects Hyperic as the Management Tool for Its Web Operations).

JBoss DNA
JBoss DNA propose un ensemble d’outils permettant la gestion de référentiels JCR (Java Content Repository) fédérant différentes sources de données : JCR, RDBMS, LDAP, UDDI, Jira, SVN. Jboss DNA permet entre autres de visualiser les relations, dépendances et similarités inter-composants. Le ‘meta-requeteur’ qui permet d’analyser ces référentiels utilise les technologies issues de l’acquisition de MetaMatrix en avril dernier. Comme le décrit ce schéma d’architecture, les clients peuvent accéder à ces services de plusieurs manières : via un serveur Web, à partir de plugins eclipse spécifiques ou directement par JDBC ou JCR.

MyEclipse Blue Edition : opération séduction à l’intention des clients WebSphere

Genuitec, l’éditeur du simple d’utilisation et économique MyEclipse, lance MyEclipse Blue Edition, version dédiée aux utilisateurs de WebSphere et destinée à remplacer Rational Application Developer.
Si l’argument de la complexité de la migration de WSAD à RAD est très discutable, les critères de coût et de simplicité sont eux tout à fait recevables.
On notera tout de même quelques bémols :

IBM propose déjà gratuitement Websphere Application Server Toolkit avec des fonctionnalités similaires à ce que propose MyEclipse Blue voire plus riches (JAX-WS, portlets, SIP, éditeur de fichiers de configuration, etc).
RAD se distingue par un Websphere Test Environment qui est fourni avec l’IDE. MyEclipse Blue n’embarque pas de runtime équivalent, Genuitec propose-t-il à ses clients d’acheter une licence Websphere par poste de développement ?

Si cette annonce laisse augurer une concurrence qui sera certainement bénéficiaire aux utilisateurs, la place de MyEclipse Blue entre Eclipse, Application Server Toolkit et RAD n’est pas encore claire.
Les fonctionnalités de MyEclipse Blue Edition rappellent le gratuit Websphere Application Server Toolkit (AST). De plus Genuintech ne résout pas le problème de la license du websphere à installer sur le poste du développeur. En revanche, la volonté marketing de cibler spécifiquement les clients Websphere est intéressante.

Le coin de la technique

Présentation de la JSR-296, Swing Application Framework

Dans cet article, Nicolas Martignole nous présente le framework applicatif pour Swing qui sera présent dans Java 7 (JSR-296). Il est vrai que depuis quelques temps Swing s’essouffle (très lourd à mettre en place) et les intérêts sont plus portés sur Eclipse RCP ou bien encore NetBeans Platform.
Cette JSR a pour objectif de simplifier les développements Swing en introduisant notamment les fonctionnalités suivantes :

Gestion du cycle de vie des applications
Chargement des ressources et gestion de l’internationalisation
Persistance de la configuration, de l’affichage, et de la position des fenêtres
Définition de la notion d’action et utilisation appropriée du moteur de thread de Swing pour effectuer de manière asynchrone certaine tâches

Pour chaque caractéristique, Nicolas Martignole nous montre des exemples de code (les parties concernant l’utilisation des ressources et des actions montrent vraiment les améliorations).
Cet article nous montre une grande simplification de l’écriture d’applications Swing (dans certains cas il fallait pratiquement réinventer la roue …) et présage un retour de Swing sur le devant de la scène !

Tuning JVM, pas une si bonne idée

Kirk Pepperdine, héros de la performance en Java, nous appelle à l’humilité en matière de tuning JVM dans My advice on JVM heap tuning, keep your fingers off the knobs! (débat sur The Server Side ici).
Les points clefs :

L’efficacité du Garbage Collector (GC) se définit suivant deux critères qui sont rarement optimaux simultanément :
– La minimisation des temps de pause : moyenne de la durée d’éxécution de la phase bloquante de chaque collection du GC.
– La maximisation du débit de l’application : pourcentage de temps pendant lequel le GC s’exécute en bloquant l’application par rapport au temps total d’exécution de l’application.
Chaque type d’application privilégiera le critère d’efficacité du GC :
– Applications interactives (GUI, web, etc) : minimisation du temps de pause pour le ressenti humain.
– Applications batch : maximisation du débit quite à avoir quelques pauses assez longues.
Le profile de consommation de ressources d’une application peut évoluer lors de son fonctionnement [1] et nécessiter différents paramètres JVM pour maximiser les performances du GC à ces différents moments.
L’activité du Garbage Collector se mesure grâce à l’activation du paramètre -verbose:gc (auquel on préférera -Xloggc:logfile.name avec les JVM Sun). Ces logs sont analyzables avec des outils gratuits tels que HP JMeter (ex HP JTune) ou IBM Extensible Verbose Tool Kit for Java (aka EVTK).
Intérêt de tuner le GC en fonction du temps de pause constaté :

Temps de pause du GC en %	*Probabilité d’améliorer les temps de réponse de l’application en tunant* le GC**
t > 10%	Probabilité forte : la collection de la mémoire est inefficace, il y a très vraisemblablement un problème sous jacent de programmation mais le tuning du GC permet parfois de pallier au problème.
5% < t < 10 %	Probabilité moyenne : il n’est pas certain qu’une tentative de tuner le GC améliore les temps de réponse de l’application.
t <5%	Probabilité très faible : il est très peu probable que le tuning du GC améliore les temps de réponse. 5 % est déjà très bon.

Les problèmes de performances du GC sont le plus souvent dus à un problème sous jacent de programmation. Si le tuning JVM permet parfois de pallier temporairement aux problèmes, une correction sur le fond est le plupart du temps incontournable.
Les JVM récentes (à partir de la version 6 chez Sun) sont par défaut auto-adaptatives pour maximiser l’efficacité du GC. Des ajustements sont mêmes réalisés au cours de l’exécution des applications dans le cas où l’application change de profile d’utilisation des ressources.
Etant donnés les mécanismes d’auto-adaptation des JVM récentes et la variabilité des paramètres optimaux du GC dus à la variabilités des types d’utilisation des applications, la taille de la Heap (aka -Xmx) est le plus souvent le seul paramètre qu’il est pertinent de tuner ; le survivor ratio peut éventuellement être tuné lui aussi. La JVM s’occupera dynamiquement des autres paramètres.

En conclusion, les JVM actuelles (BEA, IBM et Sun) sont extrêmement performantes et leurs fonctionnalités d’auto-adaptation du GC la plupart du temps plus efficace qu’un tuning manuel. Le seul paramètre à tuner est généralement la taille du heap (-Xmx) et il est parfois utile d’intervenir sur le survivor ratio. Le tuning des autres paramètres est le plus souvent une fausse bonne idée qui conduit à vérifier l’adage « there is a fine line between clever and stupid » .

[1] Différents actes de gestion exécutés à différents moments : selon l’heure de la journée, le jour de la semaine, la semaine du mois (exemples : entrées en stock le matin, expéditions en fin de journée, inventaires de fin de mois, etc)

La compilation des try/finally

Cliff Biffle nous présente dans Java 6 try/finally compilation without jsr/ret la façon dont le compilateur du jdk 6 prend en charge les blocs « finally ». Le bloc « finally » est en fait dupliqué à la fois dans le bloc « try » mais aussi dans tous les blocs « catch » possibles.