Revue de Presse Xebia

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

Agilité

• Le rôle de coach agile de A à Z

RIA

• API Flash 10
• Mashup Google Maps, Flex et BlazeDS

Le coin de la technique

• Java 64 bits, pas si souvent une bonne idée
• Effective Java, interview de Joshua Bloch
• Servlet 3.0, le classpath-scanning remis en question

Agilité

Le rôle de coach agile de A à Z

Patrick Kua nous propose, sur InfoQ, un coach agile » >abécédaire autour du rôle de *coach agile*. Cet article fait le tour du personnage (en 24 points donc) pour nous permettre de mieux appréhender sur quels éléments un coach agile se concentre, ce qu’il fait, et plus important pourquoi.
Au menu de cet abécédaire : Advice, Balance, Celebration, Daring, Encouragement, Feedback, Guidance, Humility, Infectious, Jiggle, Knowledge, Listening, Mentor, Naysayers, Obligated, Principles, Questioning, Retrospectives, Sensitive, Transparency, Unlock, Vocabulary, Welcoming, Xenodochial, Yarn, Zen.

RIA

API Flash 10

Lors de notre précédente revue de presse, nous vous parlions de la sortie de Flash 10 ainsi que des nouvelles possibilités et améliorations qui sont mises à dispositions. Malheureusement aucune documentation n’était fournie afin de tester ces nouvelles fonctionnalités. Cette erreur est réparée car Adobe nous fournit l’API pour cette version. Vous pouvez la télécharger ici. Enjoy !

Mashup Google Maps, Flex et BlazeDS

Google a récemment mis à disposition une version Flash de l’API Google Maps. L’API permet d’intégrer les cartes Google Maps dans les applications Flash/Flex, à l’image de ce que l’on peut déjà faire (et avec quelle facilité!) dans des applications HTML avec la version JavaScript.

Christophe Coenraets, Senior Technical Evangelist chez Adobe, a développé à l’aide de cette API un outil de « cartes collaboratives » qui permet de commenter à plusieurs dans une « chat room » une carte Google Maps en lui ajoutant texte ou dessin. L’application est un bon exemple d’utilisation de Flex et de BlazeDS, la technologie qui permet de faire du remoting vers un serveur Java depuis une application Flex (rappelons l’excellente série d’articles sur Flex – BlazeDS par Sébastien Arbogast).

Nous pouvons également voir dans la mise à disposition de l’API Google Maps Flash un pas de Google vers la communauté Flash/Flex. Google utilise déjà Flash dans plusieurs de ses applications (par exemple Google Analytics), mais pas encore Flex. A quand « Gmail Flex Edition » (croisons les doigts…)?

Le coin de la technique

Java 64 bits, pas si souvent une bonne idée

J. Stan Cox et Piyush Agarwal présentent dans Websphere Technical Exchange : IBM WebSphere Application Server and 64-bit platforms: 64-bit Performance Demystified les critères pour préférer la version 64 bit de Websphere à la version 32 bit.

Une application java ‘classique’ voit ses performances diminuer de 10 à 35 % lorsqu’elle est déployée sur la version 64 bit de Websphere plutôt que sur la version 32 bit.

Avantages de Java 64 bits :

• Possibilité à allouer un Java Heap largement supérieures à 2 GB (l’utilisation de pointeurs 64 bits au lieu de 32 bits permet d’allouer une quantité de mémoire quasiment illimitée à chaque processus)
• Accélération des calculs haute précision (les 64 bits d’un long ou d’un double sont lus en un cycle d’horloge avec un processeur 64 bits au lieu de deux cycles avec une CPU 32 bits)

Inconvénients de Java 64 bits :

• Consommation en mémoire sensiblement accrue à cause de la représentation des pointeurs sur 64 bits au lieu de 32 bits :
• Une application consomme souvent 50% de plus de RAM.
• Les caches des processeurs sont beaucoup moins efficaces car ils sont saturés par l’augmentation de l’espace occupé par les pointeurs.

Exemple d’accroissement de consommation de mémoire

public class MyClass { int myInt; char[] myCharArray; Map myMap; }

La checklist de Java 64 bits :

• Votre application a besoin de beaucoup plus de ~2GB de mémoire pour améliorer ses performances ?
• JVM 64 bits
• Votre application fait intensivement appel à des algorithmes de statistiques, de sécurité, d’encryption, etc qui font appel à des calculs haute précision ?
• JVM 64 bits
• Votre application a besoin d’un Heap Java un peu supérieur à 2 GB (i.e. 2~3GB) ?
• JVM 32 bits sur une plateforme 64 bits
• Vous avez besoin d’exécuter votre application sur un OS 64-bit OS bien que votre application n’exploite aucune fonctionnalité 64-bit ?
• JVM 32 bits sur une plateforme 64 bits
• Si vous avez répondu non aux questions précédentes
• JVM 32 bits sur une plateforme 32 bits

Effective Java, interview de Joshua Bloch

La seconde édition du livre très attendu « Effective Java » de Joshua Bloch est sortie lors de JavaOne début Mai. Une interview de Joshua Bloch par James Sugrue est en ligne sur dzone.
En résumé :

• Joshua a ajouté deux chapitres depuis la première édition, un sur les Generics, et un autre sur les Enums et les Annotations, et donne les bonnes pratiques à adopter au sujet de toutes les nouveautés de Java 5 (boucle for-each, autoboxing, varargs, imports statiques). Il a également modifié le chapitre traitant de la concurrence pour introduire java.util.concurrent (Tasks, Executors).
• depuis la sortie de la première version en 2001, Joshua relève quelques changements clés dans le monde Java: les environnements de développement intégrés modernes (Eclipse, IntelliJ Idea, NetBeans) ainsi que les outils d’analyse statique de code sont omniprésents, et les méthodes agiles, qui n’en étaient qu’à leurs balbutiements en 2001 se sont installées.
• si Joshua ne devait donner qu’un seul conseil à un développeur Java, ce serait le suivant: « Efforcez vous à écrire des programmes simples, clairs et corrects; ne pas le faire est complètement insensé. Le style de code est important, et rapporte énormément en termes d’exactitude, d’utilisabilité, de robustesse et de maintenabilité. C’est aussi beaucoup plus sympa d’écrire de bons programmes que de mauvais ». Il avait déjà donné ce conseil mot pour mot en 2001…
• il donne ensuite quelques conseils sur la simplicité du code, son avis sur les langages de scripting et l’apparition des closures en Java 7, et recommande une liste de livres qu’il a particulièrement appréciés.

Souhaitons à Joshua Bloch le même succès à cette seconde édition que pour la première.

Servlet 3.0, le classpath-scanning remis en question

La version 3.0 de l’API Servlet est placée sous le signe de la « framework pluggability ». Partant du constat que l’essentiel de la configuration des servlets d’une application (i.e. web.xml) est dictée par le framework MVC utilisé, l’idée directrice est de déléguer à ce framework sa configuration là où nous renseignons aujourd’hui le fichier web.xml par copier/coller des examples Struts2 et autres SpringMVC.

La piste la plus classique est d’introduire la notion de fragments de configuration ({{<web-fragment>}}) référencés dans le fichier web.xml.

Les annotations étant très à la mode ces temps-ci, une autre piste est d’utiliser un mécanisme de classpath-scanning qui exposerait automatiquement toute classe annotée @Servlet(url-mapping="/foo") trouvée dans le classpath [1]. A l’heure de la gestion des dépendances transitive « à la Maven 2 » et des classpath incertains qui en résultent, cette piste de scanning présente des risques majeurs de sécurité : une montée de version sur un jar pourrait faire apparaitre de nouveaux jars dans le classpath qui pourraient exposer des servlets non désirées. Cette piste est vivement débattue (cf InfoQ : Servlet 3.0 Features Spark Debate) et rappelle les risques de sécurité liés aux mécanismes d’auto-découverte souvent associés à l’approche Convention Over Configuration et aux annotations.

Enfin, la troisième piste, dans la lignée du HttpService, est de permettre la configuration programmatique des servlets (addServlet(), addServletMapping(), etc).

Au delà de ce débat sur le modularité des configuration, les grandes nouveautés de Servlet 3.0 :

• Configuration Programmatique des Servlet (addServlet(), addServletMapping(), etc).
• Ajout du support des annotations (dans la lignée de JAX-RS) et des fragments de configuration web.
• Ajout d’un mécanisme de suspension/reprise du traitement des requêtes qui permettra le fonctionnement asynchrones utilisé par les applications Ajax (le browser émet un requête HTTP qui est placée en attente côté serveur, sans bloquer de thread, jusqu’à l’obtention du résultat).

[1] Ce mécanisme est déjà utilisé en JPA et parfois en JAX-WS