Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Avancement des spécifications et implémentations JEE 6

RIA

• Des nouvelles d’Ext-GWT

Le coin de la technique

• Nouveau concept dans JUnit 4.7 : Rule
• Attention à votre mémoire avec String.substring()
• Sortie de Wicket 1.4
• Chouchoutez vos tests unitaires.

Evènements de notre communauté en France et à l’étranger

• Sun perd JRuby

Actualité éditeurs / SSII

Avancement des spécifications et implémentations JEE 6

Le dernier podcast des Cast Codeurs a été l’occasion de faire un tour de table des informations que chacun des speakers possédait sur JEE 6. Même s’il ne s’agit pas d’informations officielles, elles offrent un aperçu intéressant sur ce que pourrait être JEE 6 lors de sa finalisation ainsi que sur son calendrier :

• Antonio Goncalves, membre de l’Expert Group JEE 6, explique que la bataille entre les JSR-330 (Dependency Injection for Java) et JSR-299 (Java Contexts and Dependency Injection) sur le terrain de l’injection de dépendances semble partie pour se terminer de manière constructive. En effet la JSR-330 ne présentant pas d’incompatibilité particulière avec le modèle très évolué proposé par la JSR-299, les deux spécifications devraient se compléter harmonieusement. La JSR-330 définirait un ensemble d’interfaces de base que la JSR-299 viendrait étendre pour ajouter ses concepts plus élaborés. Afin de permettre cet ajustement de dernière minute, la finalisation de la spécification JEE 6 serait légèrement repoussée, la portant ainsi autour d’octobre / novembre 2009.
• Emmanuel Bernard, travaillant sur les problématiques de persistance chez JBoss, nous apprend quant à lui que l’implémentation des drafts des spécifications JEE 6 est en cours chez JBoss et devrait aboutir en version 5.2 du serveur d’application de l’éditeur avec une première implémentation non conforme au TCK, la conformité viendrait dans un deuxième temps, lors d’une version ultérieure. Il évoque la possibilité d’une présentation de ce travail lors du JBoss World de début septembre. D’autre part, la JSR-303 (Bean Validation) dont il est responsable est proche de la finalisation mais un conflit avec le JCP sur une problématique de licence complexifie l’avancement.

On ne peut que se réjouir de cette éventuelle harmonie entre les deux JSR d’injections de dépendances puisque les développeurs seraient ainsi libres de choisir la spécification sur laquelle ils se basent, en fonction de leur besoins plus ou moins complexes.

RIA

Des nouvelles d’Ext-GWT

Ext-GWT, la librairie Javascript ExtJS portée en GWT (cf. article sur la galaxie GWT), sort en version 2.0.1.
Profitons de cette sortie pour parler plus globalement du projet et de la release majeure 2.0 sortie il y a maintenant un mois.

Celle-ci apporte en effet son lot de nouveaux composants et nouvelles fonctionnalités. Ces ajouts réduisent ainsi l’écart entre les 2 projets. On trouve ainsi :

• le Tree Panel et le Tree Grid (démo), ce dernier (qui étend directement le composant Grid donc plus de binder) bénéficiant de toutes les fonctionnalités du tableau
• le row editor (démo) qui permet de modifier une ligne complète du tableau, toutes les cellules de la ligne passant en mode édition (alors qu’avant il fallait éditer toutes les cellules une par une)
• le HTML editor / Rich Text Editor (démo)
• le Live Charting (démo) qui rejoint ainsi GChart (évoquée lors d’une précédente revue de presse) et OFCGWT
• le ButtonGroup (démo) et le Status (démo)

Un travail important a été apporté sur les boutons, la barre d’outil, la gestion de l’overflow dans cette barre…

Les nouveautés étant très nombreuses, un détour par le fameux showcase permettra de les parcourir/tester.

S’agissant d’une mise à jour majeure, un guide de migration présent dans le produit décrira les changements dans l’API.

Téléchargement par ici et si (comme moi :)) vous attendez déjà la suite avec la 2.1, vous trouverez la nouvelle roadmap par là.

Le coin de la technique

Nouveau concept dans JUnit 4.7 : Rule

La version 4.7 du célèbre framework de test unitaire, JUnit, est en cours de préparation. Un nouveau concept a été dévoilé : Rule.

Ce concept va réjouir les accrocs du test automatisé par JUnit. En effet, cette fonctionnalité permettra de modifier l’exécution de vos tests, afin de les préparer à un contexte d’exécution.

Un des exemples les plus significatifs est le suivant :

 public static class HasTempFolder {
   @Rule
   public TemporaryFolder folder= new TemporaryFolder();

   @Test
   public void testUsingTempFolder() throws IOException {
     File createdFile= folder.newFile("myfile.txt");
     File createdFolder= folder.newFolder("subfolder");
     // ...
   }
 }

Grâce à cette déclaration @Rule public TemporaryFolder folder= new TemporaryFolder();, avant le test il n’y a pas besoin de créer de répertoire temporaire, après le test il n’ y a pas besoin de supprimer les répertoires et fichiers créés pendant le test. Cela permet donc plus facilement de faire des tests automatisables, répétables, et portables d’environnement à environnement.

Il existe d’autres Rules comme par exemple :

• ExternalResource: utilisable d’un fichier externe (accessible par système de fichier)
• Timeout: le test doit répondre avant un timeout
• ExpectedException: le test doit jeter des exceptions bien déterminés
• Et bien d’autres

Il y aura donc un ensemble de Rules qui permettront d’éviter de refaire des petits bouts de code personnel pour faire la même chose en une annotation.

Attention à votre mémoire avec String.substring()

Voici un article intéressant qui permet de comprendre ce qui se trouve sous le capot de la classe du JDK String : String and memory leaks ; il pourrait même vous donner une petite goutte de sueur sur le front. Même si le titre de l’article n’est pas forcement bien choisi (‘fuite mémoire’ alors qu’il s’agit plus de rétention mémoire), il nous montre simplement comment une méthode de la classe, substring, peut cacher un loup.

En effet, à des fins d’optimisation, on fait tourner le code suivant :

public static void sendEmail(String emailUrl) {
    String email = emailUrl.substring(7); // 'mailto:' prefix has 7 letters
    String userName = email.substring(0, email.indexOf("@"));
    String domainName = email.substring(email.indexOf("@"));
}

public static void main(String[] args) {
    sendEmail("mailto:user_name@domain_name.com");
}

A première vue, on a trois instances de la classes String :

• String email = "mailto:"
• String userName = "user_name@"
• String domainName = "domain_name.com"

Cependant, concrètement, en mémoire il n’y a qu’un tableau de char qui est stocké : "mailto:user_name@domain_name.com", les instances des classes String enregistrent seulement les intervalles utilisés du tableau de char.

Le piège est de manipuler une grosse chaine de caractères (qui vient d’un fichier batch par exemple) et d’utiliser substring afin de limiter la taille de la chaine et donc l’utilisation mémoire. Faux ! La chaine initiale sera toujours stockée en mémoire.

Assez déroutant !

Sortie de Wicket 1.4

Le projet Wicket continue d’évoluer et, alors que nous vous parlions d’une version 1.3.6 en mai dernier (qui a d’ailleurs fait l’objet d’une Refcard DZone), c’est la version 1.4 après un an de travail qui nous arrive dans la mains (par Yes Wicket ! et Apache Wicket).

Au menu des nouveautés : un nouveau packaging des jars Wicket (qui les rend compatibles OSGi), un seul jar pour les modules Spring et plusieurs modifications d’IModel, de ses implémentations et plus globalement des APIs pour tirer avantage de Java 5 (Generics…). L’utilisation des Generics dans le code de Wicket a commencé il y a environs un an par un sondage passionné sur la mailing-list, pour arriver seulement dans la milestone 3 de Wicket 1.4 avec autant de partisans que de détracteurs – défenseurs du support du JDK1.4- et ceci jusqu’à la release final. Le thread sur The Server Side est également impressionnant ! Pour le détail complet, rendez-vous sur le Jira du projet.

Tout comme pour Ext-GWT 2.0 (ci-dessus), une guide de migration de 1.3 vers 1.4 est disponible. Un petit téléchargement ?

Chouchoutez vos tests unitaires.

InfoQ publie un intéressant florilège : « Réalisez de meilleurs tests unitaire ».
Certains trouveront que, de nouveau, on enfonce des portes ouvertes. D’autres (comme nous), apprécierons les nombreuses réactions qui découlent de ce genre d’article, et penserons qu’il n’est jamais inutile de rappeler ces grands principes de base afin d’arrêter de voir des tests unitaires martyrisés (et inutiles) sur certains projets.
Bref, en un mot comme en mille, vos tests unitaires sont des classes de code java, qui sont vitales pour vos projet, il est donc urgent d’en prendre grand soin (nommage, documentation, refactoring…)

Evènements de notre communauté en France et à l’étranger

Sun perd JRuby

Trois développeurs clés de JRuby, à savoir Charles Nutter, Thomas Enebo et Nick Sieger, ont choisi de quitter Sun MicroSystems. Suite au rachat récent par Oracle et à l’incertitude concernant le support de JRuby par le nouveau propriétaire, ils ont décidé de rejoindre la société Engine Yard, spécialisée dans l’hébergement d’applications Ruby On Rails. Engine Yard a l’air enthousiaste à l’idée de pouvoir être le support du développement de l’offre JRuby et de la communauté qui va avec. (Source)