Blog Objet Direct

Alors que le rachat de Sun par Oracle a semé le doute, Oracle a annoncé lors de la JavaOne 2010 sa feuille de route pour Java SE… ainsi qu’un nouveau report de la sortie de Java 7.

Courant 2011, on devrait voir une version de Java 7 amputée d’une partie des évolutions initialement prévues. Cette version devrait contenir:

• JSR 292, InvokeDynamic:  Support des langages au typage dynamique
• Project Coin: Petites améliorations du langage: Switch/Case sur les String, bloc Try pour gérer des ressources…
• JSR 203, NIO2: Manipulation du système de fichiers
• JDBC 4.1:
• JSR 166y: Mise à jour des Collections et Concurrent
• Amélioration du ClassLoader et de son API
• Swing: Look’n'Feel Nimbus, composant JLayer, fenêtres translucides et ombrées
• XML/WS: Mise à jour de la pile (JAXP, JAXB, & JAX-WS)

Puis en 2012, une nouvelle version Java 8 devrait apporter le reste:

• JSR 294, Project JigSaw: extension du langage pour supporter la modularisation et découpage de la plateforme en modules
• Project Lambda: extension du langage pour permettre les expressions lambda (closure)
• JSR 308: Annotations sur les types Java
• Project Coin (Suite): Petites améliorations du langage
• Swing: composant JDatePicker

Par ailleurs, IBM a annoncé se rallier à Oracle dans le développement d’OpenJDK (l’implémentation open-source de Java 7). On va donc assister à la convergence des 3 JVM historiques: ex-Sun, ex-BEA et IBM. Qu’adviendra-t-il de Apache Harmony, une autre JVM open-source autrefois soutenue par IBM et utilisée par Google dans Android?

Tout commence par une présentation des changements et des nouvelles possibilités apportées par Java EE 5 (EJB 3.0, JPA 1.0…) et Java EE 6 (EJB 3.1, JSF 2.0…).

Puis l’auteur reprend un à un les Core J2EE patterns pour les mettre au goût du jour: Façade, Data Access Object, Transfert Object… Certains deviennent inutiles, d’autres sont transformés, d’autres tirent partie des nouveautés pour faire leur apparition. Les patterns concernant la couche présentation sont toutefois éludés.

J2EE 1.4 était synonyme de lourdeur et de développements rébarbatifs. Ici, toute complexité, tout code superflu est traqué, avec en ligne de mire une architecture simple et du code concis donc maintenable.

Le livre fait la part belle à la pratique en proposant une méthode de migration de J2EE 1.4 vers Java EE 5 et de nombreux exemples de code (DAO générique, connecteur JCA générique…).

• Titre: Real World Java EE Patterns: Rethinking Best Practices
• Auteur: Adam Bien
• ISBN: 978-1-56592-197-9

L’équipe de Kent Beck a récemment publié JUnit 4.7 qui n’apporte pas grand chose hormis la notion de Rule. Une Rule ressemble énormément à la notion d’intercepteur de l’AOP Alliance ou de TestExecutionListeners dans Spring.

A quoi celà peut-il servir en pratique? Dans les précédentes versions de JUnit 4, pour exécuter un traitement avant/après chaque méthode de test, on utilisait une méthode annotée @Before ou @After. Pour factoriser ce traitement sur plusieurs classes de tests, il fallait passer par une classe mère commune.

Dorénavant, on pourra isoler ce traitement dans une classe:

public class LogRule implements MethodRule {
    public Statement apply(final Statement base, final FrameworkMethod method, final Object target) {
        return new Statement() {
            public void evaluate() throws Throwable {
                try {
                    System.out.println("Begin " + method.getName() + " on " + target);
                    base.evaluate();
                    System.out.println("End " + method.getName() + " on " + target);
                } catch (Throwable ex) {
                    System.out.println("Exception " + method.getName() + " on " + target+": "+ex.getMessage());
                }
            }
        };
    }
}

puis le référencer dans un test, on ajoute un attribut public annoté @Rule:

public class ComplexTest {
    @Rule
    public LogRule logRule=new LogRule();
    @Test
    public void testAdd() { ... }
}

JUnit inclut quelques Rules basiques:

• ExpectedException: vérifie qu’une exception est levée (généralise @Test(expected=...) à une classe de test)
• Timeout: vérifie qu’un test ne dépasse pas une certaine durée (généralise @Test(timeout=...) à une classe de test
• ExternalResource: base pour gérer une ressource: ouvrir/fermer une connexion par exemple
  • TemporaryFolder: créer/détruit un dossier temporaire pour les tests qui produisent des fichiers
• TestWatchman: base pour observer l’exécution d’un test sans intervenir
  • TestName: donne accès au nom du test depuis la méthode de test
• Verifier: base pour vérifier l’état de l’objet de test
  • ErrorCollector: recueille les erreurs sans interrompre un test

Gageons que des projets connexes à JUnit, comme DBUnit, tireront profit de cette notion.