Revue de Presse Xebia

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

Actualité éditeurs / SSII

• MySQL 5.5
• Sonar 2.4
• Hibernate Search 3.3

Le coin de la technique

• Une Refcard sur JPA2

Actualité éditeurs / SSII

MySQL 5.5

Après le rachat de MySQL en avril 2009 il y avait des craintes qu’Oracle continue à développer cette application. Cette nouvelle version 5.5 devrait rassurer (un peu) les inquiets car elle vient avec un bon nombre d’améliorations (à lire par ailleurs cette interview de Monica Kumar, d’Oracle, sur la complémentarité des deux produits). Parmi les points intéressants à noter:

• InnoDB devient le choix par défaut pour le moteur de stockage à la place de MyISAM. Ce dernier n’était pas transactionnel, entre autres défauts, et la plupart des utilisateurs changeaient leur configuration pour InnoDB.
• meilleur gestion dans l’utilisation des processeurs multi-coeurs dans le cas d’InnoDB
• amélioration des mécanismes de réplication avec à présent un heartbeat entre le maître et les esclaves ainsi qu’un envoi d’une confirmation lorsque le premier esclave a fini sa réplication (réplication semi-synchrone).
• un nouveau statement LOAD XML pour charger des données dans un fichier xml.
• il est possible à présent de plugger son système d’authentification, par exemple le LDAP de son entreprise.

Une liste plus complète des nouvelles fonctionnalités se trouve ici. Oracle estime une amélioration de 360% des performances de MySQL comparée à l’ancienne version, à prendre bien sûr avec des pincettes en fonction des différents cas d’utilisation. Sur Windows les chiffres grimpent même jusqu’à 1500% (!) de gain, cette version proposant une meilleure intégration à ce système d’exploitation. Bref cette nouvelle version semble très recommandable.

Sonar 2.4

La sortie de Sonar 2.4 le mois dernier nous avait échappé, profitons d’un rappel d’InfoQ cette semaine pour faire un tour des nouveautés:

• Régles d’architecture: une régle consiste à définir des exclusions de référence à un package. Par exemple on peut exclure les packages .web. (couche de présentation) dans les packages .dao. (couche basse d’accès aux données). On peut aussi exclure des classes de java jugés obsolètes comme Vector ou Hashtable. Parler d’architecture à ce niveau semble un peu exagérer tant les règles sont relativement simple mais ça peut aider à améliorer du code legacy.
• Personnalisation des dashboards: une vue synthétique peuvent être proposés à des chefs de projet ou des managers tandis qu’un développeur utilisera une vue détaillée qui contiendra plus de widgets par exemple. Sonar prévoit par ailleurs d’ajouter de nouvelles widget.
• Un centre de mise à jour des plugins: une page permet à présent de lister les plugins installés, de les mettre à jours, d’en installer d’autres et de vérifier s’il existe une nouvelle version de Sonar.
• Support pour Maven 3.0: cette mise à jour est appréciable. Il est à noter qu’il existe malgrès tout une incompatibilité avec Clover.

Dans ce même article, Olivier Gaudin, de l’équipe Sonar, nous informe des prochaines évolutions. Les règles d’architectures devraient se complexifier grâce à l’ajout d’un DSL permettant d’exprimer une règle comme “La couche A ne peut être utiliser que par la couche B et C”. Il identifie également 3 axes pour diminuer sa dette technique: meilleure visibilité de la dynamique d’un projet (ajout ou suppression de violations de certaines règles), une zone de partage d’information pour les revues de code et intégration d’une version légère dans Eclipse pour anticiper avant les commits les éventuelles violations.

Hibernate Search 3.3

La nouvelle version d’Hibernate Search 3.3 est disponible. Elle contient en particulier un nouveau système de requêtes DSL qui permet de faciliter l’écriture des requêtes, Martin Fowler parlera plutôt de Fluent Interface. Voici un exemple :

Query luceneQuery = mythQB.keyword()
.onField("history")
.andField("name")
.boostedTo(5)
.andField("description")
.matching("storm")
.createQuery();

Ceci allège l’écriture et devrait donc faciliter l’élaboration de requêtes plus complexes.

Sous le capot, des modifications ont été apportées sur le mécanisme d’envoi de message pour mettre à jour les indexes, améliorant ainsi les performances. De plus ces indexes peuvent également être stockés sur une grille Infinispan (qui appartient à JBoss tout comme Hibernate Search). Pour ne rien gâcher, des nouveaux indicateurs sur les statistiques sont remontés via JMX pour mieux configurer l’outil.

Enfin Hibernate Search 3.3 est compatible avec Lucene 3.0. Bien que cette dernière version de Lucene contienne des problèmes de rétro-compatibilité, Hibernate Search les masquera. Par ailleurs il supporte le nouveau type @NumericField encore expérimental dans Lucene mais qui améliore beaucoup les performances.

Le coin de la technique

Une Refcard sur JPA2

Mike Keith, un expert en persistance Java nous avait offert la Refcard « Getting started with JPA » en septembre 2008. Il vient de récidiver pour notre plus grand plaisir avec « What’s New in JPA 2.0 »
Une Refcard sur JPA est une très bonne idée, car qui n’a jamais pesté de ne pas savoir immédiatement quelles étaient les bonnes façons d’annoter ses entités. Entre les annotations provider-specific et « normalisées JPA », il y a en effet souvent de quoi se perdre. En effet, on trouve parfois des pièges comme @Mapkey par exemple qui se comporte différemment selon le fournisseur.

La première Refcard était, tout comme JPA 1, assez basique et nous rappelait des notions comme les entity managers et les transactions (container-managed ou non) ainsi qu’une petite référence JPQL pour écrire ses requêtes…
Dans la nouvelle mouture, nous retrouvons les apports de JPA2 à la persistance comme par exemple:
– la suppression des orphelins avec l’attribut orphanRemoval de @OneToMany
– les nouvelles fonctionnalités de JPQL (tiens, on peut utiliser un ‘CASE’, bon à savoir ! ;-) )
– les requêtes typées pour ceux qui veulent éviter de caster les valeurs de retour

Et pour ceux désirant renforcer au maximum le typage de leur requêtes à la compilation, les requêtes Criteria fortement typées sont évoquées:

CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery c = cb.createQuery(Account.class);
Root acct = c.from(Account.class);
c.select(acct).where(cb.equal(acct.get(Account_.name), “Jim Morrison”));
List result = em.createQuery(c).getResultList();

Certes, la façon de générer la classe du metamodèle canonique (le Account_ avec l’underscore bizarre) n’est pas évoquée et il vous faudra trouver par vous même comment la générer avec Hibernate ou avec EclipseLink. Mais le principe d’une RefCard est justement de ne pas être exhaustif, mais de donner les clefs pour un survol rapide des possibilités. Se rafraîchir ainsi la mémoire fait généralement beaucoup de bien et cette nouvelle Refcard mérite donc de rejoindre sa grande sœur et de rester en permanence à porté de main.