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
Où sont passées les stars de Sun ?
Un an après le rachat de Sun par Oracle, qu’est il advenu des stars de Sun ? La réponse est plutôt radicale : elles se sont envolées vers des cieux plus cléments. Avant d’entrer dans plus de détails, on peut d’abord noter que la différence « génétique » entre Sun, moteur d’innovation proche d’une entreprise de recherche, et Oracle, éditeur logiciel centré sur le business, augurait de nombreux chocs culturels.
Certains ont été violents, et la rupture a été amère. C’est le cas pour James Gosling, qui a été le plus prolixe (sur son blog) au sujet de son départ, évoquant une démission qui l’a occupé à plein temps pendant plusieurs semaines. De manière comparable, Tim Bray a rejoint Google, en ne détaillant pas les raisons qui l’ont poussées à quitter Oracle mais en laissant transparaître une certaine amertume.
D’autres sont partis car Oracle ne leur donnait pas de garanties sur leur technologie : Charles Nutter et Thomas Enebo ont rejoint Engine Yard pour continuer à développer JRuby. Kohsuke Kawaguchi a monté sa société pour porter Hudson.
Enfin, certains n’ont pas reçu d’offre d’Oracle. C’était attendu pour Jonathan Schwartz et Scott McNealy qui étaient quasiment condamnés par leur position au sommet de la hiérarchie de Sun. C’était plus surprenant pour Simon Phipps, responsable de l’open source, qui occupe un poste équivalent chez ForgeRock (qui entend développer -OpenSSO- pardon OpenAM, le nom OpenSSO étant déposé).
Alors, cette vague de départs sera t’elle préjudiciable à Oracle ? Sur le plan de l’innovation, certainement. Sur un plan purement business, on peut en douter, aucun des « sous »-produits (sans que nous portions de jugement de qualité) de Sun n’étant stratégiques pour la firme de Larry Ellison. D’ailleurs, si l’on jette rapidement un œil à ceux qui sont restés, on note John Fowler, Cindy Reese, et Mike Splain, tous trois impliqués dans la branche hardware. De là à dire que c’était la principale visée d’Oracle (avec la JVM)… « Malheureusement », Oracle a aussi hérité de bébés bien encombrants, comme les JUG (voir l’article de Nicolas de Loof à ce sujet).
Le coin de la technique
Nouvelle version pour EhCache
Terracotta maintient le rythme des évolutions Ehcache, en nous livrant cette nouvelle version numérotée 2.1.
Après un mois de maturation en bêta, l’éditeur officialise donc la dernière mouture stable de son célèbre cache.
C’est surtout l’occasion d’étoffer son offre produit en ajoutant notamment un plugin de monitoring permettant de surveiller en temps réel les métriques essentielles du cache. Grâce à lui, les développeurs pourront affiner la configuration du cache, par contre pour l’utiliser en production il vous faudra une version payante.
Le support Websphere a bénéficié lui aussi d’améliorations pour garantir à ses utilisateurs l’accès à toutes les fonctionnalités du produit.
Cela inclut tout naturellement, le support la solution Terracotta Web Session, un cluster de session web à haute disponibilité, déjà disponible pour Weblogic, JBoss, Tomcat et Jetty.
L’utilisation de JTA a aussi été largement améliorée, les configurations standalone et Hibernate sont à présent supportées, ce qui permet de couvrir l’intégralité des stratégies Hibernate.
En dernier point d’amélioration, le développement a été axé vers de meilleures performances et un paramétrage fin des SLAs. C’est par exemple la fonctionnalité NonStopCache qui permet de contrôler le timeout des opérations sur le cache, voire même de passer automatiquement d’un cache sur disque à un cache en mémoire vive en cas d’indisponibilité. Par ailleurs le UnlockedReadsView offre une vue non consistante du cache. Dans les faits, elle ignore les verrous d’écriture et ne pose pas de verrou de lecture, l’équivalent d’un READ_UNCOMITTED avec des performances très largement accrues.
jucProfiler
Il y a quelques années, certains se sont arrachés les cheveux pour détecter les contentions dans un programme massivement parallélisé. Malheureusement pour les amoureux des nœuds au cerveau, les développeurs de chez IBM se sont penchés sur le sujet et proposent un outil pour diagnostiquer ce type de problèmes : jucProfiler (pour java.util.concurrent). Le principe est simple : instrumenter le bytecode de certaines classes de java.util.concurrent.locks et tracer les appels à java.util.concurrent.locks.LockSupport et java.util.concurrent.locks.AbstractQueuedSynchronizer.
L’outil génère ensuite un rapport permettant d’identifier deux types de problèmes sur les thread, consomateurs de temps :
- du temps de contention : un verrou est réservé par un autre thread.
- du temps d’attente : le thread est en
wait.
Et cerise sur le gâteau, pour ceux d’entre vous lassés de devoir diagnostiquer des problèmes de performances en analysant des fichiers texte de trois pieds de long, un éditeur graphique est même fourni.
Comme le dit justement la conclusion de l’article, la généralisation de la programmation parallèle nous oblige à nous armer de meilleurs outils. Il semblerait que jucProfiler en fasse partie. Si l’un de nos lecteurs a eu l’opportunité de l’utiliser en condition réelle, nous sommes bien sûr preneurs d’un retour d’expérience.
Maven Enforcer
Sonatype a récemment mis en ligne une présentation en deux parties (ici et là) sur le plugin Maven Enforcer.
Ce plugin permet de définir des règles afin d’obtenir un build Maven reproductible sur différents environnements. Il permet entre autres :
- de spécifier une version ou une plage de versions de Maven,
- de spécifier une version ou une plage de versions du JDK,
- de spécifier une architecture (OS/CPU) sur laquelle s’exécute le build,
- de s’assurer que le projet ne contient pas de dépendances (transitives) vers des versions non explicites (SNAPSHOT, LATEST ou RELEASE),
- de s’assurer que le projet n’utilise pas de plugins ayant une version non explicite (SNAPSHOT, LATEST ou RELEASE),
- de bannir des dépendances,
- de définir ses propres règles (en Java ou avec un script BeanShell).
La présentation met l’accent sur la nécessité de fixer les versions des dépendances et des plugins afin d’éviter qu’un build ne devienne instable suite à la publication d’une nouvelle version d’une dépendance ou d’un plugin. Il préconise notamment l’emploi de Maven en version supérieure à 2.0.9 pour laquelle le POM parent n’utilise plus que des versions explicites des plugins.
Elle recommande aussi de spécifier une version du JDK (1.5.x par exemple) afin d’éviter différentes problématiques telles que l’utilisation d’API non supportées ou la différence de comportement de certains plugins Maven en fonction de la version de la JVM sur laquelle ils sont exécutés.
Une fois les bonnes pratiques exposées, la configuration des différentes règles permettant d’effectuer les vérifications est abordée.
Le plugin Maven Enforcer est encore peu connu mais gagnerait à être utilisé pour éviter des problèmes récurrents. Cette présentation est un bon point de départ pour aborder sa mise en place.