Encore une librairie ?

Chacun de nous a ses petites habitudes. Je pense que la connaissance du vaste écosystème des projets open-source du monde Java est assez difficile. Pourtant ce qui fait la force de notre plateforme, c’est bien cette quantité impressionnante de projets et de librairies. Quel est l’intérêt d’utiliser une librairie plutôt que de la développer soi-même ? Le gain de temps, le fait qu’une librairie populaire est plutôt bien testée par la communauté et enfin la possibilité de trouver de l’aide sur Internet, ou des articles d’exemples, comme celui-ci.

Les packages

La librairie propose les packages suivants:
- com.google.common.annotations
- com.google.common.base
- com.google.common.collect
- com.google.common.io
- com.google.common.net
- com.google.common.primitives
- com.google.common.util.concurrent

La librairie Google Collections a été regroupée à l’intérieur de Google Guava. La librairie tire son nom de la goyave, fruit à peau verte et à coeur rouge, qui réserve une surprise à celui qui ouvre le fruit en deux.

Le package com.google.common.annotations ne contient que 4 annotations pour marquer certaines classes comme étant compatible ou non avec GWT, pour marquer en @Beta les classes susceptibles de changer. L’annotation @VisibleForTesting permet de marquer une méthode comme ayant été rendu visible uniquement pour les tests. Je pense à un setId dans une entité comme dans l’article sur JPA2.

Le package com.google.common.base regroupe plusieurs familles de classes. Tout ce qui permet de manipuler les chaînes de caractères, ensuite ce qui permet d’introduire des notions de programmation fonctionnelle en Java et enfin différentes classes pratiques comme Objects ou Preconditions que nous avions vu dans l’article sur JPA et les tests.

Classes utilitaires pour la manipulation de caractères et de chaines

• CaseFormat
• CharMatcher
• Charsets
• Joiner
• Splitter
• Strings

La classe CharMatcher est une version plus lisible des Regex et des Patterns matchers de Java. Je vous conseille l’usage de cette classe pour rendre votre code plus lisible. Par exemple je m’en servirai pour valider si le nom d’un utilisateur ne contient pas de caractères interdits dans mon application de cette façon :

package org.letouilleur.sample;

import com.google.common.base.CharMatcher;
import com.google.common.base.Preconditions;
import org.junit.Test;

import static org.junit.Assert.*;

public class TestGuava {

    @Test
    public void testCharMatcherIsin() {
        String username = "Nicolas";
        String badUserName = "Nic ! olas,, @ et ?";
        assertTrue(validateUsername(username));
        assertFalse(validateUsername(badUserName));
    }

    /**
     * Validates that the username does not contains one of !@?(,)
     *
     * @param username is the username to validate.
     *
     * @return true if none of the char in username is in the restricted list.
     */
    public static boolean validateUsername(String username) {
        Preconditions.checkNotNull(username);
        // Je ne veux pas de caractères spéciaux dans les mots de passe ou les noms d'utilisateur
        CharMatcher noSpecialChars = CharMatcher.noneOf("!@?(,)").negate();
        if (noSpecialChars.matchesNoneOf(username)) {
            System.out.println(username + " is a valid username");
            return true;
        }
        System.out.println("Please do not use one of !@?(,) in your username value.");
        return false;
    }

}

Types fonctionnels

Google Guava permet d’écrire certaines parties de votre programme Java de manière plus fonctionnelle.
C’est ce qui m’intéresse le plus dans Guava. Google a regroupé un ensemble de fonctions qui apporte un peu de vision fonctionnelle à votre programmation. Un exemple simple : j’ai remplacé des NamedQuery assez compliquées sur des Entités JPA par des appels avec Guava. Ceci permet d’extraire la partie métier et de la rentre visible et testable dans le code. J’ai pu le faire car la table en base est simple et petite.

• Function,
  Functions
• Predicate,
  Predicates
• Supplier,
  Suppliers

Je vous proposerai dans un deuxième article une présentation détaillée de Google Guava.

Autres

• Defaults
• FinalizableReference and subtypes
• Objects
• Preconditions
• Throwables

La classe Preconditions s’importe en général de manière statique dans votre code. Elle regroupe beaucoup de méthodes simples comme checkNotNull(Object o) qui remplace 3 lignes de if(o==null) throw new NullPointerException. Mais surtout, Preconditions permet de rendre plus expressif votre code métier.

Sans Guava
if (count < = 0) {
       throw new IllegalArgumentException("must be positive: " + count);
}
devient
   checkArgument(count > 0, "must be positive: %s", count);

Continuer la lecture et aller à la partie 2 : faire du fonctionnel avec Guava

Références

- Le site de Google Guava
- Une série d’article en Anglais sur Google Guava
- Exploring Google Guava par Dan Lewis d’OCI.

La blogosphère, ma boîte GMail, Twitter, tout le monde ne parle que de ça… Encore une fois Twitter a été pour moi le premier moyen d’être informé, suivi par la mailing list JavaPosse toujours au courant de ce genre de rumeurs.

Bon mon avis sur la question: attendons quelques jours avant de crier au loup. Les avis sont partagés, certains prédisent la mort de MySQL, d’autres de la JVM de SUN qui ferait doublon avec « autre-jvm » d’oracle… Bien malin celui qui peut parler au nom d’Oracle… Projets secrets ? Rapprochement programmé ?

A suivre

Didier a déjà publié une news sur son blog, je le laisse donc passer devant, le Touilleur Express vous donnera d’autres informations demain dans la soirée.

Stay Tuned !
Il y a encore d’autres choses à venir.

Voir :
L’annonce sur le blog SpringSource du support de Groovy
http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html

Il existe 3 paramètres possible pour l’élément lazy lors de la définition d’une association dans une entité :
– false
– true
– extra

...
        
            
            
        
...

Le test est simple : j’édite le fichier Item.hbm.xml et j’active le chargement tardif (lazy=true). Le code Java affiche le nom de l’item chargé puis ensuite le nombre d’enchères sur l’Item en utilisant la méthode size() sur le HashSet.

Code Java

        long start = System.currentTimeMillis();
        Session session = HibernateUtil.getSessionFactory().getCurrentSession();
        session.beginTransaction();
        item1 = (Item) session.load(Item.class, new Integer(id));
        logger.info("Item name is ["+item1.getName()+"]");
        logger.info("Size of Bids Set : "+ item1.getBids().size())  ;
        logger.info("Ellapsed: " + (System.currentTimeMillis() - start));

Résultats de l’exécution

   Hibernate: /* load org.touilleur.hibernate.v1.Item */
            select item0_.ITEM_ID as ITEM1_0_0_, item0_.name as name0_0_, item0_.price as price0_0_
            from ITEM item0_ where item0_.ITEM_ID=?
INFO 2009-03-09 22:12:20,234 [Demo Hibernate] : Item name is [Item 1]
   Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */
            select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_,
                      bids0_.BID_ID as BID1_1_0_,
                      bids0_.amount as amount1_0_, bids0_.date as date1_0_,
                      bids0_.ITEM_ID as ITEM4_1_0_
           from BID bids0_ where bids0_.ITEM_ID=?
INFO 2009-03-09 22:12:20,244 [Demo Hibernate] : Size of Bids Set : 10
INFO 2009-03-09 22:12:20,244 [Demo Hibernate] : Ellapsed: 23

On constate qu’Hibernate effectue tout d’abord une requête sur la table Item, affiche le nom de l’item puis ensuite effectue le chargement de l’ensemble des Bids en spécifiant l’id de l’Item. Je vois plusieurs soucis : le chargement de l’ensemble des colonnes de la table Bid, la deuxième requête, et finalement la requête SQL n’est pas franchement optimisée : nous voulons afficher la taille de la collection, or Hibernate charge l’ensemble des éléments…
Ce qui veut dire que 10 objets de type Bid seront créés et que la taille du hashSet de bids sera calculée en effectuant un appel à la méthode hashSet.size().
Je ne suis pas sûr d’être clair : pour retourner la taille de la collection, Hibernate charge toute la collection et retourne la taille de la liste… Vous imaginez la consommation en terme de mémoire ? Je serai presque tenté de dire qu’Hibernate n’est pas franchement écologique.

Voyons ce qu’il se passe lorsque le chargement tardif est désactivé en mettant lazy=false dans l’attribut set, dans le fichier Item.hbm.xml

INFO 2009-03-09 22:17:20,756 [Demo Hibernate] : testLazyFalse
   Hibernate: /* load org.touilleur.hibernate.v1.Item */
            select item0_.ITEM_ID as ITEM1_0_0_, item0_.name as name0_0_,
                      item0_.price as price0_0_ from ITEM item0_
            where item0_.ITEM_ID=?
   Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */
            select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_,
                      bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_,
                     bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_
            from BID bids0_
            where bids0_.ITEM_ID=?
INFO 2009-03-09 22:17:20,777 [Demo Hibernate] : Item name is [Item 1]
INFO 2009-03-09 22:17:20,778 [Demo Hibernate] : Size of Bids Set : 10
INFO 2009-03-09 22:17:20,778 [Demo Hibernate] : Ellapsed: 21

Nous constatons que la seule différence, c’est qu’Hibernate effectue toutes les requêtes avant l’exécution du code…
Mais encore une fois, si notre code se contentait d’afficer par exemple le nombre d’enchères (ici 10) nous aurions chargé encore une fois l’arbre d’enchères pour rien. Bref pas d’optimisation en vue pour l’instant.

Voyons pour terminer ce qu’Hibernate fait lorsqe le paramètre lazy est mis à extra :

...
        
            
            
        
...

L’exécution nous donne le résultat suivant:

   Hibernate: /* load org.touilleur.hibernate.v1.Item */
          select item0_.ITEM_ID as ITEM1_0_0_, item0_.name as name0_0_,
                    item0_.price as price0_0_
          from ITEM item0_
          where item0_.ITEM_ID=?
INFO 2009-03-09 22:25:10,702 [Demo Hibernate] : Item name is [Item 1]
   Hibernate:
             select count(BID_ID) from BID where ITEM_ID =?
INFO 2009-03-09 22:25:10,707 [Demo Hibernate] : Size of Bids Set : 10
INFO 2009-03-09 22:25:10,707 [Demo Hibernate] : Ellapsed: 17

Cette fois-ci Hibernate utilise un SELECT COUNT pour calculer la taille de la collection sans la charger, ce qui est d’une part plus rapide, et d’autre part plus économique en terme de données chargées et d’instance préparées.

La valeur lazy est un moyen d’indiquer à Hibernate que l’objet Père (ici Item) contient une collection d’enfants (Bids) très grande. Si votre application calcule la taille du Set avec la méthode size() ou que vous testez par exemple si la collection est vide avec getBids().isEmpty(), Hibernate effectue une requête de type SELECT COUNT, ce qui revient donc à éviter de charger le contenu des enchères.

C’est donc une optimisation possible dans une application afin d’éviter de charger un arbre d’objet trop important dans votre code.

Si vous utilisez les annotations voici comment déclarer ce paramère :

// Code de la classe Item
@OneToMany
@org.hibernate.annoations.LazyCollection(org.hibernate.annotations.LazyCollectionOption.EXTRA)
private Set bids = new HashSet();

Voilà pour la deuxième partie, j’ai encore quelques idées que je vous proposerai dans d’autres articles prochainement.

Hibernate est un moteur de mapping object-relationnel (ORM) qui permet de charger des données venant d’une base de données, vers le monde Java en réduisant la quantité de code Java à écrire.
Vous définissez une classe Java, ensuite un fichier de mapping au format XML, et Hibernate offre alors un moyen pour charger, modifier et effacer vos données. Il dispose aussi d’un cache de requête afin d’optimiser les appels et d’éviter des aller-retours inutiles avec la base de données. Un cache de second niveau offre un moyen très puissant mais délicat à maîtriser pour partager vos données et réduire le coût de la base de données dans une application.
Il est possible d’utiliser soit des annotations sur la classe Java, soit des fichiers XML. Sachez que si vous utilisez des annotations, un fichier de configuration XML peut vous permettre de surcharger le mapping des annotations, et donc d’éviter d’être bloqué par du code déjà compilé sur lequel vous n’avez pas le contrôle.

Objectifs de l’article

La première partie de l’article est assez dictatique pour ceux qui ne connaissent pas Hibernate 3. La seconde partie sera plus intéressante pour les utilisateurs qui souhaitent voir quelques options avancées d’Hibernate. Nous verrons comment gérer efficacement les relations entre les objets, les stratégies de chargement et les différentes types d’option de chargement tardif (Lazy instanciation).

Code source de l’article

Pour les besoins de cet article j’ai préparé un projet simple avec maven2, que vous pouvez télécharger en fin d’article. Le code est distribué sous licence Creatives Commons v2 avec quelques restrictions sur la non modification et l’interdiction d’utiliser le code à des fins commerciales sans mon accord.

Si vous souhaitez tester quelques fonctionnalités en lisant l’article, vous aurez besoin de Java 5 et de Maven 2.0.6 minimum pour compiler et tester le code. J’utilise un test unitaire JUnit 3.8 simple pour lancer les différents tests, un simple « mvn test » en ligne de commande vous permet de compiler le code et de lancer la base de données embarquée HSQLDB.

Un peu de relationnel

J’ai repris un exemple simple pour passer en revue quelques caractéristiques d’Hibernate plus ou moins connues.
Prenons tout d’abord la classe Item, correspondant à un article.
Un Item est caractérisé par son nom, son prix et une clé d’identité. Un constructeur vide sans argument est requis pour qu’Hibernate puisse décorer cette classe avec un proxy avec la librairie CGLIB, sans quoi une exception org.hibernate.InstantiationException sera levée par Hibernate. De même il est recommandé de ne pas déclarer de classe finale comme entité si vous souhaitez qu’Hibernate puisse utiliser un proxy. Si malgré tout vous êtes obligés de déclarer une méthode finale, il faudra alors désactiver le chargement tardif (lazy=false) dans la configuration de l’entité [1]

public class Item {
    private Integer id;
    private String name;
    private float price;
    private Set<Bid> bids=new HashSet<Bid>();

    public Item() {

    }

    public Item(String name, float price){
        //...
    }
     // Getter, setter, equals, hashCode et toString
}

La classe Bid (enchère en anglais) est une offre émise par un acheteur sur notre Item. Les attributs sont l’heure de l’enchère et son montant.

public class Bid {
    private Integer id;
    private float amount;
    private Date date;
    private Item item;

    public Bid(){
    }

    // getter, setter, hashCode, equals
}

Le fichier de mapping Hibernate Item.hbm.xml permet à Hibernate d’effectuer le mapping entre la classe Item et notre base de données. La relation un-vers-plusieurs (un Item contient plusieurs Bids) est définie avec un set. Nous utiliserons une table de jointure ITEM_BIDS, le chargement tardif sera désactivé (lazy=false), nous indiquons à Hibernate que la relation inverse est déclarée dans Bid (inverse=true).

    <hibernate-mapping>

    <class name="org.touilleur.hibernate.v1.Item" table="ITEM">
        <id name="id" column="ITEM_ID">
            <generator class="native"/>
        </id>
        <property name="name"/>
        <property name="price"/>
        <set name="bids" table="ITEM_BIDS"
                                       lazy="false"
                                       inverse="true"
                                       fetch="select"
                                       cascade="all">
            <key column="ITEM_ID" not-null="true"/>
            <one-to-many class="org.touilleur.hibernate.v1.Bid"/>
        </set>
    </class>

</hibernate-mapping>

Hibernate recommande d’utiliser des associations symétriques. Dans notre application, une enchère sans article n’a pas de sens. Nous configurons donc notre association many-to-one avec l’attribut not-null à true dans le fichier Bid.hbm.xml:

<hibernate-mapping>
    <class name="org.touilleur.hibernate.v1.Bid" table="BID">
        <id name="id" column="BID_ID">
            <generator class="native"/>
        </id>
        <property name="amount"/>
        <property name="date"/>
        <many-to-one name="item"
                               column="ITEM_ID"
                               class="org.touilleur.hibernate.v1.Item"
                               not-null="true"/>
    </class>

</hibernate-mapping>

Stratégie de chargement de l’association

Hibernate évite au maximum de faire appel à la base de données, et tend à limiter le nombre de requête, afin d’alléger le traitement. Par défaut la stratégie de chargement tardive qui permet d’optimiser les performances, peut provoquer quelques moments difficile lorsque surgit l’exception LazyInitializationException.

Une exception de type LazyInitializationException sera renvoyée par Hibernate si une collection ou un proxy non initialisé est accédé en dehors de la portée de la Session, e.g. lorsque l’entité à laquelle appartient la collection ou qui a une référence vers le proxy est dans l’état « détachée ».

Cela se produit dans les architectures 3-tiers, où le tiers de présentation Web est séparé physiquement de l’ejbtiers pour des raisons de sécurité. Ce type d’architecture soufre de plusieurs soucis : si vous interdisez l’accès à la base de données à partir du web-tiers, il faudra donc que la stratégie de chargement tardive d’Hibernate soit désactivée (lazy=false). Dans le cas où nous souhaitons charger un Item, toutes les enchères associées seront alors chargées. Imaginez que pour seulement afficher le nom de l’Item, nous allons aussi charger 1500 Bids par exemple…
Il est alors important de configurer Hibernate finement et d’utiliser des jointures afin d’éviter trop de requêtes.

Dans un premier temps, nous allons regarder les différentes possibilités de chargement d’une association, en essayant différentes valeurs pour l’attribut fetch de l’attribut set. La valeur par défaut lorsqu’elle n’est pas précisée est « select ». Les 3 valeurs possibles sont select, join et subselect. Nous désactivons le chargement tardif en ajoutant le mot clé « lazy=false » dans le fichier Item.hbm.xml.

Fetch strategy par défaut en mode lazy=false

Pour ce test, dans le test unitaire SelectTest, nous allons voir comment il est possible de changer la stratégie de chargement directement dans le code. Avant cela, regardons comment travaille Hibernate par défaut avant de tester d’autres modes de chargement. Par défault lorsque FetchMode est à DEFAULT comme ci-dessous, Hibernate se repose sur ce que vous avez déclaré dans votre fichier de mapping, Item.hbm.xml pour nous.

// voir org.touilleur.hibernate.SelectTest
 Item item1 = (Item) session.createCriteria(Item.class)
                .setFetchMode("bids", FetchMode.DEFAULT)
                .add(Restrictions.idEq(id))
                .uniqueResult();

La configuration du chargement de l’association s’effectue dans le fichier de configuration hibernate.cfg.xml à l’aide de l’attribut fetch. La valeur par défaut est select, les 2 autres valeurs possibles sont join et subselect. Voyons d’abord par défaut le comportement d’Hibernate :

       <set name="bids" table="ITEM_BIDS" lazy="false" inverse="false"
                        fetch="select" cascade="all">

Pour continuer, exécutez la méthode testSelectOneItemWithDefault.
La console affiche les requêtes SQL suivantes:
...
INFO 2009-02-27 22:24:21,788 [Demo Hibernate] : Starting selectOneItemWithDefault
Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_,
this_.price as price0_0_ from ITEM this_ where this_.ITEM_ID = ?
Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_,
bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_,
bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=?
INFO 2009-02-27 22:24:21,791 [Demo Hibernate] : Loaded item1 with a FetchMode set to DEFAULT...

2 requêtes sont nécessaires pour effectuer le chargement de l’unique Item.

Chargement de l’ensemble des Items

Le test unitaire testSelecTAllItemsWithDefaultFetchMode sélectionne les 2 Items de notre base et affiche ensuite les 2 items. La méthode toString de la class Item force le chargement de la liste des enchères. Nous avons désactivé le chargement tardif (lazy=false) et il est donc normal de voir Hibernate charger les Bids.

Que se passe-t-il lorsque nous exécutons ce code ?

INFO 2009-03-03 10:18:30,670 [Demo Hibernate] : testSelecTAllItemsWithDefaultFetchMode - begin
Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_, this_.price as price0_0_ from ITEM this_
Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=?
Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=?
INFO 2009-03-03 10:18:30,704 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=7, amount=107.0, date=2009-03-03 10:18:30.637}, Bid{id=10, amount=110.0, date=2009-03-03 10:18:30.643}, Bid{id=6, amount=106.0, date=2009-03-03 10:18:30.632}, Bid{id=8, amount=108.0, date=2009-03-03 10:18:30.638}, Bid{id=2, amount=102.0, date=2009-03-03 10:18:30.626}, Bid{id=4, amount=104.0, date=2009-03-03 10:18:30.629}, Bid{id=1, amount=101.0, date=2009-03-03 10:18:30.625}, Bid{id=9, amount=109.0, date=2009-03-03 10:18:30.639}, Bid{id=5, amount=105.0, date=2009-03-03 10:18:30.63}, Bid{id=3, amount=103.0, date=2009-03-03 10:18:30.628}], name='TV LCD', price=340.0}
INFO 2009-03-03 10:18:30,706 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=20, amount=144.0, date=2009-03-03 10:18:30.657}, Bid{id=15, amount=125.0, date=2009-03-03 10:18:30.651}, Bid{id=13, amount=43.0, date=2009-03-03 10:18:30.647}, Bid{id=16, amount=116.0, date=2009-03-03 10:18:30.652}, Bid{id=14, amount=84.0, date=2009-03-03 10:18:30.648}, Bid{id=11, amount=10.0, date=2009-03-03 10:18:30.645}, Bid{id=17, amount=137.0, date=2009-03-03 10:18:30.654}, Bid{id=19, amount=139.0, date=2009-03-03 10:18:30.656}, Bid{id=12, amount=22.0, date=2009-03-03 10:18:30.646}, Bid{id=18, amount=138.0, date=2009-03-03 10:18:30.655}], name='Plasma', price=1230.0}
INFO 2009-03-03 10:18:30,709 [Demo Hibernate] : testSelecTAllItemsWithDefaultFetchMode - end

<hibernate-mapping>

    <class name="org.touilleur.hibernate.v1.Item" table="ITEM">
        <id name="id" column="ITEM_ID">
            <generator class="native"/>
        </id>
        <property name="name"/>
        <!-- The fetch join strategy uses a select join query to load with one transact the set of bids -->
        <property name="price"/>
 <-- LAZY est à TRUE -->
        <set name="bids" table="ITEM_BIDS" lazy="true" inverse="true" fetch="select" cascade="all">
            <key column="ITEM_ID" not-null="true"/>
            <one-to-many class="org.touilleur.hibernate.v1.Bid"/>
        </set>
    </class>

</hibernate-mapping>

Je relance le même test unitaire :

INFO 2009-03-03 10:26:38,910 [Demo Hibernate] : testSelecTAllItemsWithDefaultFetchMode - begin
Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_, this_.price as price0_0_ from ITEM this_
Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=?
INFO 2009-03-03 10:26:38,937 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=1, amount=101.0, date=2009-03-03 10:26:38.864}, Bid{id=10, amount=110.0, date=2009-03-03 10:26:38.883}, Bid{id=8, amount=108.0, date=2009-03-03 10:26:38.878}, Bid{id=3, amount=103.0, date=2009-03-03 10:26:38.867}, Bid{id=6, amount=106.0, date=2009-03-03 10:26:38.871}, Bid{id=2, amount=102.0, date=2009-03-03 10:26:38.866}, Bid{id=9, amount=109.0, date=2009-03-03 10:26:38.879}, Bid{id=5, amount=105.0, date=2009-03-03 10:26:38.87}, Bid{id=7, amount=107.0, date=2009-03-03 10:26:38.876}, Bid{id=4, amount=104.0, date=2009-03-03 10:26:38.868}], name='TV LCD', price=340.0}
Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=?
INFO 2009-03-03 10:26:38,944 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=18, amount=138.0, date=2009-03-03 10:26:38.896}, Bid{id=11, amount=10.0, date=2009-03-03 10:26:38.885}, Bid{id=20, amount=144.0, date=2009-03-03 10:26:38.898}, Bid{id=16, amount=116.0, date=2009-03-03 10:26:38.893}, Bid{id=14, amount=84.0, date=2009-03-03 10:26:38.888}, Bid{id=19, amount=139.0, date=2009-03-03 10:26:38.897}, Bid{id=15, amount=125.0, date=2009-03-03 10:26:38.892}, Bid{id=12, amount=22.0, date=2009-03-03 10:26:38.886}, Bid{id=13, amount=43.0, date=2009-03-03 10:26:38.887}, Bid{id=17, amount=137.0, date=2009-03-03 10:26:38.895}], name='Plasma', price=1230.0}
INFO 2009-03-03 10:26:38,947 [Demo Hibernate] : testSelecTAllItemsWithDefaultFetchMode - end


Cette fois-ci nous constatons qu’Hibernate effectue une requête que lorsque cela devient nécessaire, ce qui est adapté dans la majorité des cas.
Lorsque le mode lazy est désactivé, Hibernate effectue n+1 requêtes sans jointure. Cela peut entraîner un très grand nombre de requêtes vers la base. Nous allons donc voir comment optimiser dans ce cas précis le chargement des associations.

Fetch strategy à join et lazy=false

Si nous ne pouvons pas utiliser le chargement tardif, il est alors intéressant d’utiliser une requête et d’effectuer une jointure entre la table Item et la table Bid. Pour cela il suffit de changer de stratégie lors de la requête. Nous passons maintenant le mode de récupération (FetchMode) à JOIN :

// voir la class org.touilleur.hibernate.SelectTest
 Item item1 = (Item) session.createCriteria(Item.class)
                .setFetchMode("bids", FetchMode.JOIN)
                .add(Restrictions.idEq(id))
                .uniqueResult();

Si vous savez qu’il sera toujours plus intéresant d’utiliser une requête par jointure vous pouvez aussi changer la stratégie dans le fichier Item.hbm.xml :

<set name="bids" table="ITEM_BIDS" lazy="false" inverse="true" fetch="join" cascade="all">


Le test selectOneItemWithJoin nous montre alors qu’une seule requête est exécutée, et qu’une jointure externe gauche entre la table Item et la table Bid permet de retrouver un Item avec 0 ou plusieurs Bid.


INFO 2009-02-27 22:24:21,772 [Demo Hibernate] : Starting selectOneItemWithJoin
Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_1_, this_.name as name0_1_, this_.price as price0_1_,
bids2_.ITEM_ID as ITEM4_3_, bids2_.BID_ID as BID1_3_, bids2_.BID_ID as BID1_1_0_, bids2_.amount as amount1_0_,
bids2_.date as date1_0_, bids2_.ITEM_ID as ITEM4_1_0_
from ITEM this_ left outer join BID bids2_
on this_.ITEM_ID=bids2_.ITEM_ID where this_.ITEM_ID = ?
INFO 2009-02-27 22:24:21,775 [Demo Hibernate] : Loaded item1 with a FetchMode set to JOIN

Notez qu’Hibernate utilise une jointure externe de la table Item vers la table Bid, cela nous donne alors en simplifiant le code SQL la requête suivante :
select i.*,b* from ITEM i
outer join BID b
on i.ITEM_ID=b.ITEM_ID

Par défaut il n’y a donc pas de critères de distinction, et nous nous retrouvons alors avec 20 résultats, ce qui sera pratique pour remplir un tableau mais qui n’est pas forcément souhaitable pour votre code.

INFO 2009-03-03 10:30:53,041 [Demo Hibernate] : testSelecTAllItemsWithJoinFetchMode - begin
Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_1_, this_.name as name0_1_, this_.price as price0_1_, bids2_.ITEM_ID as ITEM4_3_, bids2_.BID_ID as BID1_3_, bids2_.BID_ID as BID1_1_0_, bids2_.amount as amount1_0_, bids2_.date as date1_0_, bids2_.ITEM_ID as ITEM4_1_0_ from ITEM this_ left outer join BID bids2_ on this_.ITEM_ID=bids2_.ITEM_ID
INFO 2009-03-03 10:30:53,072 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=3, amount=103.0, date=2009-03-03 10:30:52.999}, Bid{id=8, amount=108.0, date=2009-03-03 10:30:53.01}, Bid{id=6, amount=106.0, date=2009-03-03 10:30:53.003}, Bid{id=10, amount=110.0, date=2009-03-03 10:30:53.014}, Bid{id=5, amount=105.0, date=2009-03-03 10:30:53.002}, Bid{id=2, amount=102.0, date=2009-03-03 10:30:52.998}, Bid{id=7, amount=107.0, date=2009-03-03 10:30:53.009}, Bid{id=4, amount=104.0, date=2009-03-03 10:30:53.001}, Bid{id=9, amount=109.0, date=2009-03-03 10:30:53.011}, Bid{id=1, amount=101.0, date=2009-03-03 10:30:52.997}], name='TV LCD', price=340.0}
INFO 2009-03-03 10:30:53,074 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=3, amount=103.0, date=2009-03-03 10:30:52.999}, Bid{id=8, amount=108.0, date=2009-03-03 10:30:53.01}, Bid{id=6, amount=106.0, date=2009-03-03 10:30:53.003}, Bid{id=10, amount=110.0, date=2009-03-03 10:30:53.014}, Bid{id=5, amount=105.0, date=2009-03-03 10:30:53.002}, Bid{id=2, amount=102.0, date=2009-03-03 10:30:52.998}, Bid{id=7, amount=107.0, date=2009-03-03 10:30:53.009}, Bid{id=4, amount=104.0, date=2009-03-03 10:30:53.001}, Bid{id=9, amount=109.0, date=2009-03-03 10:30:53.011}, Bid{id=1, amount=101.0, date=2009-03-03 10:30:52.997}], name='TV LCD', price=340.0}
...
Message répété 20 fois
...
INFO 2009-03-03 10:30:53,125 [Demo Hibernate] : testSelecTAllItemsWithJoinFetchMode - end

Pour ajouter une clause DISTINCT, nous pouvons modifier notre critère et utiliser un ResultTransformer :

List l = session.createCriteria(Item.class)
                .setFetchMode("bids", FetchMode.JOIN)
                .setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY)
                .list();

En exécutant à nouveau notre test voici le résultat :

INFO 2009-03-03 10:43:31,196 [Demo Hibernate] : testSelecTAllItemsWithJoinFetchMode - begin
Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_1_, this_.name as name0_1_, this_.price as price0_1_, bids2_.ITEM_ID as ITEM4_3_, bids2_.BID_ID as BID1_3_, bids2_.BID_ID as BID1_1_0_, bids2_.amount as amount1_0_, bids2_.date as date1_0_, bids2_.ITEM_ID as ITEM4_1_0_ from ITEM this_ left outer join BID bids2_ on this_.ITEM_ID=bids2_.ITEM_ID
INFO 2009-03-03 10:43:31,229 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=8, amount=108.0, date=2009-03-03 10:43:31.162}, Bid{id=7, amount=107.0, date=2009-03-03 10:43:31.16}, Bid{id=2, amount=102.0, date=2009-03-03 10:43:31.149}, Bid{id=6, amount=106.0, date=2009-03-03 10:43:31.154}, Bid{id=10, amount=110.0, date=2009-03-03 10:43:31.167}, Bid{id=9, amount=109.0, date=2009-03-03 10:43:31.163}, Bid{id=3, amount=103.0, date=2009-03-03 10:43:31.15}, Bid{id=5, amount=105.0, date=2009-03-03 10:43:31.153}, Bid{id=1, amount=101.0, date=2009-03-03 10:43:31.147}, Bid{id=4, amount=104.0, date=2009-03-03 10:43:31.151}], name='TV LCD', price=340.0}
INFO 2009-03-03 10:43:31,232 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=19, amount=139.0, date=2009-03-03 10:43:31.181}, Bid{id=17, amount=137.0, date=2009-03-03 10:43:31.179}, Bid{id=15, amount=125.0, date=2009-03-03 10:43:31.176}, Bid{id=13, amount=43.0, date=2009-03-03 10:43:31.171}, Bid{id=11, amount=10.0, date=2009-03-03 10:43:31.169}, Bid{id=12, amount=22.0, date=2009-03-03 10:43:31.17}, Bid{id=14, amount=84.0, date=2009-03-03 10:43:31.172}, Bid{id=20, amount=144.0, date=2009-03-03 10:43:31.182}, Bid{id=18, amount=138.0, date=2009-03-03 10:43:31.18}, Bid{id=16, amount=116.0, date=2009-03-03 10:43:31.177}], name='Plasma', price=1230.0}
INFO 2009-03-03 10:43:31,235 [Demo Hibernate] : testSelecTAllItemsWithJoinFetchMode - end


Voir la FAQ Hibernate [Hibernate does not return distinct results for a query with outer join fetching enabled for a collection (even if I use the distinct keyword)]

La sélection par jointure est donc une option possible. Nous sommes passés de 3 requêtes à une seule requête, ce qui est une optimisation permettant de réduire le nombre de requête SQL. Encore une fois, c’est à vous et à votre DBA de décider de la meilleur stratégie, il ne faut donc pas appliquer à l’aveugle les paramètres. Les jointures sont efficaces si vos colonnes de jointure sont correctement indexées, il est donc important de s’assurer que votre administrateur de base de données a aussi validé vos changements.

Fetch mode par subselect

Hibernate propose un mode de sélection moins connu et pourtant très efficace sur les associations, le mode subselect. L’idée est simplement d’utiliser le résultat d’une première requête comme critère de la sélection de la deuxième requête pour effectuer une requête plus efficace.

Ce que nous avons vu en premier, en mode lazy=false et fetch=select, c’est qu’Hibernate effectue n+1 requêtes pour charger la liste des Bids pour chacun des Items.

/* Retrouve la liste des Items */
select * from ITEM

/* Retrouve la list des Bids pour chaque Item */
select * from BID  where ITEM_ID = 12
select * from BID  where ITEM_ID = 34
select * from BID  where ITEM_ID = 37
select * from BID  where ITEM_ID = 39

Il y deux façons d’optimiser ce type de requête : soit utiliser le paramètre batch-size dans l’element set du fichier Item.hbm.xml, soit utiliser une requête de sous sélection. Je ne sais pas si ce mode est supporté par toutes les bases de données, mais voici le principe :
- Sélectionner les Items
- Sélectionner les Bids en utilisant les ID des items précedemment trouvé

/* Retrouve la liste des Items */
select * from ITEM

/* Retrouve la list des Bids pour chaque Item */
select * from BID  where ITEM_ID IN( 12, 34, 37, 39)

Pour cela il n’est pas possible de changer le mode de sélection dans le code, il faut éditer le fichier Item.hbm.xml et préciser que le fetch type est subselect

<hibernate-mapping>
  <class name="org.touilleur.hibernate.v1.Item" table="ITEM">
        <id name="id" column="ITEM_ID">
            <generator class="native"/>
        </id>
        <property name="name"/>
        <!-- Nous testons subselect -->
        <property name="price"/>
        <set name="bids" table="ITEM_BIDS" lazy="false"
               inverse="true"
               fetch="subselect"
               cascade="all">
            <key column="ITEM_ID" not-null="true"/>
            <one-to-many class="org.touilleur.hibernate.v1.Bid"/>
        </set>
    </class>

</hibernate-mapping>

Après avoir édité le fichier Item.hbm.xml, le test unitaire testSelecTAllItemsWithSubSelectFetchMode nous montre que deux requêtes sont exécutées au lieu de n+1 dans le cas du mode « select » ou une seule requête dans le cas du mode « join » :

INFO 2009-03-03 11:06:36,678 [Demo Hibernate] : testSelecTAllItemsWithSubSelectFetchMode - begin
Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_, this_.price as price0_0_ from ITEM this_
Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */
select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_,
bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_,
bids0_.ITEM_ID as ITEM4_1_0_
from BID bids0_
where bids0_.ITEM_ID
in (select this_.ITEM_ID from ITEM this_)
INFO 2009-03-03 11:06:36,711 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=7, amount=107.0, date=2009-03-03 11:06:36.646}, Bid{id=3, amount=103.0, date=2009-03-03 11:06:36.636}, Bid{id=8, amount=108.0, date=2009-03-03 11:06:36.647}, Bid{id=2, amount=102.0, date=2009-03-03 11:06:36.635}, Bid{id=6, amount=106.0, date=2009-03-03 11:06:36.64}, Bid{id=5, amount=105.0, date=2009-03-03 11:06:36.639}, Bid{id=1, amount=101.0, date=2009-03-03 11:06:36.633}, Bid{id=9, amount=109.0, date=2009-03-03 11:06:36.648}, Bid{id=4, amount=104.0, date=2009-03-03 11:06:36.637}, Bid{id=10, amount=110.0, date=2009-03-03 11:06:36.652}], name='TV LCD', price=340.0}
INFO 2009-03-03 11:06:36,714 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=14, amount=84.0, date=2009-03-03 11:06:36.657}, Bid{id=18, amount=138.0, date=2009-03-03 11:06:36.664}, Bid{id=17, amount=137.0, date=2009-03-03 11:06:36.663}, Bid{id=20, amount=144.0, date=2009-03-03 11:06:36.666}, Bid{id=15, amount=125.0, date=2009-03-03 11:06:36.66}, Bid{id=12, amount=22.0, date=2009-03-03 11:06:36.655}, Bid{id=13, amount=43.0, date=2009-03-03 11:06:36.656}, Bid{id=19, amount=139.0, date=2009-03-03 11:06:36.665}, Bid{id=16, amount=116.0, date=2009-03-03 11:06:36.661}, Bid{id=11, amount=10.0, date=2009-03-03 11:06:36.654}], name='Plasma', price=1230.0}
INFO 2009-03-03 11:06:36,716 [Demo Hibernate] : testSelecTAllItemsWithSubSelectFetchMode - end

L’intérêt de ce mode de sélection est de récuperer en deux requêtes l’ensemble des Items et ensuite des Bids. Si vous faites enfin le test en mode « lazy=true » vous verrez par ailleurs qu’Hibernate n’effectue pas de chargement tardif mais qu’il charge toutes les données. Le mode de sélection en « SUBSELECT » limite à deux requêtes le nombre d’interrogation nécessaire, le tout sans jointure. C’est donc une option intéressante à tester selon la logique de votre application.

Fetch mode par batch size

La 4ème technique pour améliorer les chargements par lot est d’activer l’option batch-size. Afin de montrer son fonctionnement nous allons d’abord limiter la taille de chargement à 1 pour le nombre d’Item et le nombre de collection de Bid :

<hibernate-mapping>

    <class name="org.touilleur.hibernate.v1.Item" table="ITEM" batch-size="1">
        <id name="id" column="ITEM_ID">
            <generator class="native"/>
        </id>
        <property name="name"/>
        <!-- The fetch join strategy uses a select join query to load with one transact the set of bids -->
        <property name="price"/>
        <set name="bids" table="ITEM_BIDS"
              lazy="false"
              inverse="true"
              fetch="select"
              cascade="all"
              batch-size="1">
            <key column="ITEM_ID" not-null="true"/>
            <one-to-many class="org.touilleur.hibernate.v1.Bid"/>
        </set>
    </class>

</hibernate-mapping>

Nous voyons qu’à l’exécution, Hibernate effectue une requete pour récuperer une liste de deux Items puis ensuite deux requêtes pour chacun des Items. En mode lazy, nous aurions simplement vu que la deuxième requête de chargement aurait été effectuée plus tardivement


INFO 2009-03-03 13:19:19,261 [Demo Hibernate] : testSelecTAllItemsWithSubSelectFetchMode - begin
Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_, this_.price as price0_0_ from ITEM this_
Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=?
Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=?
INFO 2009-03-03 13:19:19,294 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=2, amount=102.0, date=2009-03-03 13:19:19.217}, Bid{id=5, amount=105.0, date=2009-03-03 13:19:19.221}, Bid{id=3, amount=103.0, date=2009-03-03 13:19:19.218}, Bid{id=10, amount=110.0, date=2009-03-03 13:19:19.233}, Bid{id=7, amount=107.0, date=2009-03-03 13:19:19.227}, Bid{id=4, amount=104.0, date=2009-03-03 13:19:19.219}, Bid{id=1, amount=101.0, date=2009-03-03 13:19:19.215}, Bid{id=9, amount=109.0, date=2009-03-03 13:19:19.23}, Bid{id=8, amount=108.0, date=2009-03-03 13:19:19.229}, Bid{id=6, amount=106.0, date=2009-03-03 13:19:19.222}], name='TV LCD', price=340.0}
INFO 2009-03-03 13:19:19,297 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=19, amount=139.0, date=2009-03-03 13:19:19.247}, Bid{id=16, amount=116.0, date=2009-03-03 13:19:19.243}, Bid{id=11, amount=10.0, date=2009-03-03 13:19:19.236}, Bid{id=18, amount=138.0, date=2009-03-03 13:19:19.246}, Bid{id=13, amount=43.0, date=2009-03-03 13:19:19.237}, Bid{id=20, amount=144.0, date=2009-03-03 13:19:19.248}, Bid{id=14, amount=84.0, date=2009-03-03 13:19:19.238}, Bid{id=15, amount=125.0, date=2009-03-03 13:19:19.242}, Bid{id=17, amount=137.0, date=2009-03-03 13:19:19.245}, Bid{id=12, amount=22.0, date=2009-03-03 13:19:19.236}], name='Plasma', price=1230.0}
INFO 2009-03-03 13:19:19,300 [Demo Hibernate] : testSelecTAllItemsWithSubSelectFetchMode - end


Le chargement par lot est une technique efficace qui permet de précharger un nombre défini de proxy non initialisé si un premier proxy est accedé. Il y a donc l’optimisation au niveau du chargement de l’entité (Item) et l’optimisation au niveau du chargement de la collection (Bid).

Le chargement par lot pour notre classe Item fonctionne de la manière suivante : dans votre base imaginons que nous ayons 10 Items, chacun de ces Items référencent un Acheteur avec une relation un-à-un. La relation est mappée avec un proxy en mode lazy= »true ». Si par défaut vous chargez la liste des Items puis qu’ensuite vous appelez la méthode getBuyer() pour retrouver l’acheteur, Hibernate effectuera alors 10 requêtes SQL (10 items).
Le chargement par lot permet de spécifier à Hibernate la taille d’une fenêtre de chargement, en utilisant les clés primaires ou les clés étrangères, qui ici seraient dans la table BUYER.


<class name="Item" batch-size="10">...</class>

Hibernate exécutera non plus 10 requêtes SQL mais une seule pour charger l’ensemble des acheteurs. Idéalement vous l’aurez deviné, ce batch-size correspond au nombre d’éléments affichés sur une page Web, dans un tableau paginé par exemple.

Ensuite il est possible d’activer le chargement par lot sur les collections. Notre Item a une collection de Bid. Imaginons que je charge mes 10 Items dans ma Session Hibernate. Par défaut, chaque appel à getBids() entrainera alors une requête SQL, soit 10 requêtes pour charger chacune des collections. En spécifiant une taille de batch comme ci-dessous il est possible d’optimiser le nombre d’éléments préchargés et donc de réduire le nombre de requête SQL :

<class name="Item">
    <set name="Bid" batch-size="3">
        ...
    </set>
</class>

Pour 7 enchères, Hibernate chargera alors 3,3,1 en effectuant 3 requêtes au lieu de 7 requêtes par exemple. Cela permet de réduire encore une fois le nombre de requête, et cette valeur doit être guidée par le code de votre application et l’usage que vous en faîtes.
Pour cette raison il est souvent plus souhaitable de définir la taille du batch au niveau du code comme dans ci-dessous:

 List l = session.createCriteria(Item.class)
                    .setFetchSize(10)
                    .list();

Petite astuce au passage : si vous souhaitez limiter le nombre de résultat retourné, vous connaissez sans doute la commande setMaxResults(int i).

List l = session.createCriteria(Item.class)
                    .setMaxResults(10)
                    .list();

Par curiosité je me suis un peu demandé pourquoi Hibernate prend plus de temps que la même requête SQL exécutée sur ma base de test. En fouillant un peu je me suis aperçu qu’il est intéressant de préciser la taille du batch afin de ne récuperer qu’un seul lot :

List l = session.createCriteria(Item.class)
                    .setMaxResults(10)
                    .setFetchSize(10)
                    .list();

Essayez sur votre code vous verrez la différence.

Conclusion de la première partie

Lorsque le chargement tardif ne peut pas être utilisé, il est important de vérifier que la stratégie par défaut d’Hibernate n’entraine pas un nombre de requêtes SQL trop importantes. Il est possible de limiter ce nombre en utilisant des jointures ou des selections imbriquées. A vous ensuite d’optimiser vos réglages selon votre application.

Dans la deuxième partie nous allons voir les 3 paramètres différents de chargement des collections.

J’espère que vous aurez apprécié. Si vous voulez aller un peu plus loin, il ne vous reste plus qu’à télécharger le code de l’article et à commencer à tester les différentes configurations possibles d’Hibernate. Pour les personnes à la recherche d’un tutorial sur Hibernate, la première partie vous montre un exemple simple de mapping pour commencer à apprendre Hibernate.

Bonne lecture et à bientôt pour la deuxième partie !

Code source de l’article
ArticleTouilleur_hibernate.tar.gz

Tout d’abord c’est l’annonce officielle de la sortie de JavaFX 1.0. De nombreuses conférences sur ce thème, une BOF, bref il y a eu un effet d’annonce très bien calibré. Ce qui m’a le plus intéressé, c’est les surprises de Java 7. Finalement la prochaine version de Java ne sortira pas avant début 2010, ce qui me fait penser que SUN et la communauté veulent prendre le temps nécessaire pour sortir une version vraiment innovante.

Lors de la Keynote du jeudi matin, Mark Reinold a un peu changé le programme de la présentation, car au lieu de « Java SE 7 updated », sa présentation a commencé par « Modularity in Java SE ». Avant tout, avis de déces : la JSR-277 (Java Modules) est morte et enterrée. Cela a bien fait rire tout le monde lors de la présentation des JavaPosse l’après-midi. On parle maintenant de la JSR-294. Son blog (avec un look un peu soviétique) vous donnera l’actualité de ce qu’il se passe… car il y a un coté un peu people qui ne m’intéresse pas tellement.

De son point de vue, OSGi n’est pas suffisant pour répondre aux soucis d’obésité de la JVM. L’objectif est d’offrir un système plus modulaire pour que le kernel de base soit plus léger. Cela s’appliquera à la JVM, au JRE et au SDK. Le débat de fond reste de savoir si cette modularité doit faire partie de Java 7 de facto ou pas…

Concernant les nouveautés du JDK 7, Mark a parlé de beaucoup de JSR dont voici la liste (sans doute incomplète car je n’ai pas tout eu le temps de récuperer) :
- JSR 292 pour le support des langages Dynamiques
- JSR 203 NIO2 (entrees / sorties nouvelle implémentation)
- JSR 296 Swing Application framework (voir cet article)
- JSR 308 vise à étendre les endroits où nous pourrions utiliser les Annotations en Java…
- JSR 166 package Concurrency avec de nouvelles Class pour ce package de Doug Lea (Fork/Join, Phasers, LinkedTransferQueue, ConcurrentReferenceHashMap, et Fences)
- Smart Rethrow et surtout MultiCatchException, petite astuce qui permettra d’éviter les multiples catch(x) catch(y) et catch(z) qui n’améliorent pas la lisibilité du code.
- JSR 295 Beans binding (?)

Le plus fun sera d’apprendre que il n’y aura pas de closures en Java 7 ce qui a bien fait rire tout le monde (JSR 295). Après tout ce temps perdu sur les blogs, on a pas vraiment compris ensuite ce qu’ils comptent faire… Bref longue vie à Groovy qui a déjà ce système depuis sa création. Plus sérieusement, cela veut peut-être dire que les closures… en s’en fiche en Java. Certes c’est élégant, mais moi ma bonne grosse application de gestion… elle s’en fiche.

Au final ce qu’il faut retenir : l’objectif de Java 7 sera d’offrir un système modulaire afin que selon le type d’application, le nombre de classes et le temps de démarrage soit encore plus léger que Java 6. Il y a aura peu de révolutions du côté de la syntaxe, plus des chantiers comme un support des langages dynamiques. Tout ceci devrait occuper SUN et la communauté l’an prochain.

Références complémentaires:
http://java.dzone.com/articles/java-7-update-mark-reinhold-de
http://blogs.sun.com/darcy/
Blog de Mark Reinhold

Si vous avez déjà eu à tester JavaMail dans votre application, je parle de tests d’intégrations, sachez qu’il existe une petite librairie bien sympathique pour « mocker » du code Java. Disons que vous souhaitez envoyer un email de votre interface Web pour remettre un mot de passe à zéro. Comment écrire un test unitaire sans utiliser un vrai serveur SMTP ?

Mock JavaMail permet de simuler une boîte aux lettres et de se comporter comme un serveur SMTP pour l’envoi, un serveur POP3 ou IMAP pour la réception.

Prenons par exemple un projet très simple. Voici tout d’abord la dépendance que j’ai ajoutée à mon fichier pom.xml :

       
            org.jvnet.mock-javamail
            mock-javamail
            1.7
        

Prenons ensuite un test unitaire qui génère un email afin de tester l’envoi. Tout d’abord voici le code à améliorer qui génère un email afin de l’envoyer via smtp

 private void sendSmtpEmail(Address from) throws MessagingException {
        Properties props = new Properties();
        //props.put("mail.smtp.host", "localhost");

        Session session = Session.getDefaultInstance(props, null);
        session.setDebug(true);

        // create a message
        SMTPMessage msg = new SMTPMessage(session);
        msg.setSubject("A simple test email");
        msg.setFrom(from);
        msg.setContent("Email content","text/plain");
        msg.setRecipients(MimeMessage.RecipientType.TO , "destinataire@yourdomain.com");

        Transport tr = session.getTransport("smtp");
        tr.connect("localhost", "anyUsername",  "password");

        msg.saveChanges();      // don't forget this
        tr.sendMessage(msg, msg.getAllRecipients());
        tr.close();
    }

Mock JavaMail se fiche pas mal du username et du password, donc vous pouvez mettre ce que vous voulez, tant que le serveur SMTP dans la construction de l’instance Transport est bien « localhost ».

Ensuite un exemple de code dans lequel je déclare un objet de type Mailbox, afin d’envoyer un email.

    public void testSendMail() throws Exception {
        Address address = new InternetAddress("destinataire@yourdomain.com");
        Mailbox mailbox = new Mailbox(address);

        assertTrue("The mock mailbox is not empty whereas it should be", mailbox.isEmpty());

        // Classical code to send an email to a smtp server
        sendSmtpEmail(address);

        // Get a fresh reference to the mailbox
        mailbox=Mailbox.get("destinataire@yourdomain.com");
        // Check that a mail has been received
        assertFalse("The mock mailbox is empty", mailbox.isEmpty());

        Message message=mailbox.get(0);
        assertEquals("A simple test email",message.getSubject());
    }

Vous pouvez maintenant facilement tester l’envoi des messages de votre application et vous assurer que tout fonctionne sans devoir passer par un FakeSMTP

Allez, rendez-vous à Devoxx.
J’ai déjà récupéré mon teeshirt du Paris JUG grâce à David, la fin de semaine s’annonce chargée.

Là vous êtes perplexe… ne faites pas les timides je sais que vous n’avez rien compris.
Reprenons le problème avec un oeil différent : dans un restaurant, nous avons 5 serveurs qui se chargent de poser des commandes sur un passe-plat. Le passe-plat est une table où les serveurs posent les commandes. Les commandes les plus récentes sont posées à droite, de sorte que la commande du client qui attend depuis le plus longtemps se trouve à gauche.

Les commandes sont enregistrées sur un tableau. Les 3 cuisiniers surveillent la liste des commandes. Un cuisinier dépile toujours la commande la plus à gauche posée sur ce passe-plat. Peu importe qu’un serveur l’ai posé à l’instant ou pas, il doit toujours traiter la commande la plus à gauche sur le passe-plat.

Je sais que c’est simpliste comme image, mais vous allez comprendre pourquoi lorsque je vais sortir la nouveauté de la saison 2008…

Ensuite nous voulons que les cuisiniers attendent qu’au moins 3 commandes soient présentes, afin d’optimiser la cuisson des aliments. L’idée est que lorsque 3 commandes sont présentes et que les cuisiniers n’ont rien à faire, ces 3 commandes sont retirées du passe-plat.
Imaginez comment vos cuisiniers vont surveiller le passe-plat et attendre de manière synchrone que 3 commandes soient présentes…

Enfin comme nous ne voulons pas non plus laisser les clients en attente trop longtemps, une commande qui a plus de 5 mn d’ancienneté a le droit d’être dépilée… sans qu’il ne soit nécessaire d’attendre 2 autres commandes… Ok ?

Enfin pour terminer il faut aussi penser aux serveurs : nous souhaitons qu’ils attendent lorsque 5 commandes sont posées sur le passe-plat afin d’éviter d’engorger notre passe-plat pour rien. Dès qu’un cuisinier dépile une commande, le serveur sera alors débloqué et pourra poser sa commande sur le passe-plat.

Donc nous avons une liste chaînée, avec de la synchronisation. Nous avons aussi une notion de seuil à respecter pour les consommateurs. Et enfin nous avons une notion de temps limite pour s’amuser encore plus…

Il est temps de ressortir ses manuels et de regarder ce que nous avons en stock. Parlons d’abord « deque » (prononcer deck).

C’est quoi une deque ?
A prononcer « Deck », une deque est une « double-ended queue » soit une liste à double entrée en français dans le texte (on ne dit paspas double sortie en français, cela fait un peu trop tunning…). C’est une liste chainée composée d’une tête et d’une queue. La différence avec une Fifo est qu’il est possible de dépiler soit au début, soit à la fin là où une Fifo ne vous laisse accéder qu’à la fin. Java 6 propose une interface Deque. Les méthodes remarquables sont limpides :
 

La méthode addFirst permet d’ajouter une nouvelle commande au début de notre passe-plat. Cependant si nous souhaitons faire passer une commande avant toutes les autres, la méthode addLast nous donne un droit d’écriture afin de placer notre commande à la fin.

La méthode peekLast permet à un cuisinier de s’assurer que la dernière tâche en attente n’est pas dans la pile depuis un certain temps… Mais ce n’est pas encore la solution que je souhaite vous présenter.

BlockingDeque
Une BlockingDeque représentée par l’interface java.util.concurrent.BlockingDeque est une deque qui va attendre d’être non vide avant de laisser un consommateur dépiler un élément. Clairement : nos cuisiniers attendent sagement qu’une commande arrive. C’est aussi une Queue capable de faire attendre un serveur lorsque la liste est pleine, c’est de cette manière que nous allons faire attendre les serveurs lorsque la BlockingQueue est pleine.

En Java, l’interface BlockingDeque est constituée entre autres des méthodes suivantes:

public boolean offer (E element, long timeout, TimeUnit unit)

public boolean offerFirst(E e, long timeout, TimeUnit unit) throws InterruptedException

public boolean offerLast(E element,long timeout, TimeUnit unit)

La méthode offer permet d’ajouter un nouvel élément à la fin de la liste, en attendant une certaine quantité de temps précisée par la valeur timeout précisé par l’unité de TimeUnit. Si jamais finalement l’entrée n’a pas été ajoutée au bout du temps t, alors la méthode retournera false. Sinon elle retourne true. Pratique non ?

La méthode offerFirst permet de faire passer une commande devant toutes les autres, tout en restant avec la contrainte du timeout comme précédemment.

Du côté de nos consommateurs, les méthodes suivantes permettent soit de bloquer jusqu’à ce qu’une commande soit disponible, soit d’attendre tout en respectant un timeout.

Les méthodes takeFirst et takeLast sont bloquantes :

public E takeFirst()
public E takeLast()

Les méthodes pollFirst() et pollLast() permettent d’examiner et d’attendre que la liste se remplisse, tout en restant dans un certain intervalle de temps comme précédemment :

public E pollFirst(long timeout, TimeUnit unit)
public E pollLast(long timeout, TimeUnit unit)

LinkedBlockingDeque
Cette classe est une implémentation en Java de l’interface et permet de fixer une capacité maximum afin de limiter le nombre d’éléments dans la liste :

public LinkedBlockingDeque()
public LinkedBlockingDeque(java.util.Collection< ? extends E> c)
public LinkedBlockingDeque(int capacity)

Un exemple complet

Voici un exemple complet avec un Serveur et un Cuisinier. Ces deux objets accèdent la même BlockingQueue. La capacité de la queue est de 5 commandes.
Pour faire simple : le serveur ajoute un Integer à la BlockingQueue toutes les 300 millisecondes. Le cuisinier prend un élément toutes les 3000 millisecondes. Si le Serveur fonctionne correctement, au bout de 1500 ms (5 x 300) la queue des commandes sera pleine. Dans ce cas les 5 autres commandes suivantes seront mises en attente automatiquement, le Serveur sera bloqué.

import java.util.concurrent.BlockingDeque;

/**
 * A very simple producer class to demonstrate BlockingDeque functionnality.
 *
 * @author N.Martignole
 */
public class Serveur implements Runnable {
    private String name;
    private BlockingDeque<Integer> deque;
    // nous allons avoir 10 commandes a la suite
    private int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

    public Serveur(String name, BlockingDeque<Integer> deque) {
        this.name = name;
        this.deque = deque;
    }

    public void run() {
        for (int i = 0; i < 10; i++) {
            try {
                deque.putFirst(numbers[i]);
                System.out.println(name + " place une nouvelle commande #" + numbers[i]);
                System.out.println(name + " affiche l'état de la queue: " + deque +"\n");
                Thread.sleep(300);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
         }
   }
}

Voyons la classe du cuisinier :

import java.util.concurrent.BlockingDeque;

public class Cuisinier implements Runnable {
    private String name;
    private BlockingDeque<Integer> deque;

    public Cuisinier(String name, BlockingDeque<Integer> deque) {
        this.name = name;
        this.deque = deque;
    }

    public void run() {
        for (int i = 0; i < 10; i++) {
            try {
                int j= deque.takeLast();
                System.out.println("Cuisinier "+ name + " prend " + j);
                System.out.println(name + " regarde la queue: " + deque + "\n");
                Thread.sleep(3000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

Enfin il nous faut une class de Test pour tester le tout:

import java.util.concurrent.BlockingDeque;
import java.util.concurrent.LinkedBlockingDeque;

public class Tester {

    public static void main(String[] args) {
        // Creation d'une queue pour notre passe plat de 5 cases
        BlockingDeque<Integer> deque = new LinkedBlockingDeque<Integer>(5);

        // Creation d'un serveur et d'un cuisinier pour faire simple
        Runnable serveur = new Serveur("Serveur", deque);
        Runnable cuisinier = new Cuisinier("Cuisinier", deque);

        // Lance le tout
        new Thread(serveur).start();
        new Thread(cuisinier).start();
    }
}

Avez-vous constaté que le Serveur attend 300 millisecondes avant de poser une nouvelle commande là où le cuisinier attend 3000 ms ? Pour 10 éléments, au bout de 1500 ms le Serveur sera donc bloqué car la queue sera pleine. Nous devrions donc le voir attendre jusqu’à ce qu’une place se libère.

Le résultat est intéressant :

Serveur place une nouvelle commande #1
Serveur affiche l'état de la queue: [1]

Cuisinier commence la commande #1
Cuisinier regarde le passe-plat []

Serveur place une nouvelle commande #2
Serveur affiche l'état de la queue: [2]

Serveur place une nouvelle commande #3
Serveur affiche l'état de la queue: [3, 2]

Serveur place une nouvelle commande #4
Serveur affiche l'état de la queue: [4, 3, 2]

Serveur place une nouvelle commande #5
Serveur affiche l'état de la queue: [5, 4, 3, 2]

Serveur place une nouvelle commande #6
Serveur affiche l'état de la queue: [6, 5, 4, 3, 2]

Cuisinier a terminé la commande #1
Cuisinier commence la commande #2
Serveur place une nouvelle commande #7
Cuisinier regarde le passe-plat [7, 6, 5, 4, 3]

Serveur affiche l'état de la queue: [7, 6, 5, 4, 3]

Cuisinier a terminé la commande #2
Cuisinier commence la commande #3
Serveur place une nouvelle commande #8
Cuisinier regarde le passe-plat [8, 7, 6, 5, 4]

Serveur affiche l'état de la queue: [8, 7, 6, 5, 4]

Cuisinier a terminé la commande #3
Cuisinier commence la commande #4
Cuisinier regarde le passe-plat [8, 7, 6, 5]

Serveur place une nouvelle commande #9
Serveur affiche l'état de la queue: [9, 8, 7, 6, 5]

Cuisinier a terminé la commande #4
Cuisinier commence la commande #5
Serveur place une nouvelle commande #10
Cuisinier regarde le passe-plat [10, 9, 8, 7, 6]

Serveur affiche l'état de la queue: [10, 9, 8, 7, 6]

Le serveur a terminé de placer les commandes
Cuisinier a terminé la commande #5
Cuisinier commence la commande #6
Cuisinier regarde le passe-plat [10, 9, 8, 7]

Cuisinier a terminé la commande #6
Cuisinier commence la commande #7
Cuisinier regarde le passe-plat [10, 9, 8]

Cuisinier a terminé la commande #7
Cuisinier commence la commande #8
Cuisinier regarde le passe-plat [10, 9]

Cuisinier a terminé la commande #8
Cuisinier commence la commande #9
Cuisinier regarde le passe-plat [10]

Cuisinier a terminé la commande #9
Cuisinier commence la commande #10
Cuisinier regarde le passe-plat []

Cuisinier a terminé la commande #10
Cuisinier a terminé de traiter les commandes

Comme on peut le constater, avec peu d’effort il est possible d’implémenter un système synchrone propre, sans faire appel à du vieux code comme synchronized, wait ou join. C’est l’une des forces de l’api Concurrent en Java qui permet de programmer des cas complexes comme celui-ci en quelques lignes.

Pour terminer voyons le code du Tester avec 2 Cuisniers. J’y ajoute une notion de timeout afin que les cuisiniers attendent 1000 ms au maximum lorsque la queue est vide. Pourquoi cela ? Car chacun des 2 cuisiniers va traiter 5 commandes, bien que cela ne soit pas déterministe. Je ne peux pas baser mon code uniquement sur la supposition que chacun des cuisiniers traite 5 commandes, rien ne me dit que par exemple le GarbageCollector ne va pas perturber mon code. Pour cela la solution est simple, il suffit d’ajouter un timeout comme nous l’avons vu au début de cette article, dans la class Cuisinier .

La méthode run() de Cuisinier devient alors :

 public void run() {
        for (int i = 0; i < 5; i++) {
            try {
                int j= deque.pollLast(1000, TimeUnit.MILLISECONDS);

                System.out.println(name + " commence la commande #" + j);
                System.out.println(name + " regarde le passe-plat " + deque + "\n");
                Thread.sleep(3000);
                System.out.println(name+ " a terminé la commande #"+j);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println(name+" a terminé de traiter les commandes");
    }

Le résultat de l’exécution donnera alors :

Serveur place une nouvelle commande #1
Serveur affiche l'état de la queue: [1]

Cuisinier 1 commence la commande #1
Cuisinier 1 regarde le passe-plat []

Serveur place une nouvelle commande #2
Serveur affiche l'état de la queue: [2]

Cuisinier 2 commence la commande #2
Cuisinier 2 regarde le passe-plat []

Serveur place une nouvelle commande #3
Serveur affiche l'état de la queue: [3]

Serveur place une nouvelle commande #4
Serveur affiche l'état de la queue: [4, 3]

Serveur place une nouvelle commande #5
Serveur affiche l'état de la queue: [5, 4, 3]

Serveur place une nouvelle commande #6
Serveur affiche l'état de la queue: [6, 5, 4, 3]

Serveur place une nouvelle commande #7
Serveur affiche l'état de la queue: [7, 6, 5, 4, 3]

Cuisinier 1 a terminé la commande #1
Cuisinier 1 commence la commande #3
Serveur place une nouvelle commande #8
Cuisinier 1 regarde le passe-plat [8, 7, 6, 5, 4]

Serveur affiche l'état de la queue: [8, 7, 6, 5, 4]

Cuisinier 2 a terminé la commande #2
Cuisinier 2 commence la commande #4
Cuisinier 2 regarde le passe-plat [9, 8, 7, 6, 5]

Serveur place une nouvelle commande #9
Serveur affiche l'état de la queue: [9, 8, 7, 6, 5]

Cuisinier 1 a terminé la commande #3
Cuisinier 1 commence la commande #5
Cuisinier 1 regarde le passe-plat [9, 8, 7, 6]

Serveur place une nouvelle commande #10
Serveur affiche l'état de la queue: [10, 9, 8, 7, 6]

Le serveur a terminé de placer les commandes
Cuisinier 2 a terminé la commande #4
Cuisinier 2 commence la commande #6
Cuisinier 2 regarde le passe-plat [10, 9, 8, 7]

Cuisinier 1 a terminé la commande #5
Cuisinier 1 commence la commande #7
Cuisinier 1 regarde le passe-plat [10, 9, 8]

Cuisinier 2 a terminé la commande #6
Cuisinier 2 commence la commande #8
Cuisinier 2 regarde le passe-plat [10, 9]

Cuisinier 1 a terminé la commande #7
Cuisinier 1 commence la commande #9
Cuisinier 1 regarde le passe-plat [10]

Cuisinier 2 a terminé la commande #8
Cuisinier 2 commence la commande #10
Cuisinier 2 regarde le passe-plat []

Cuisinier 1 a terminé la commande #9
Cuisinier 1 a terminé de traiter les commandes
Cuisinier 2 a terminé la commande #10
Cuisinier 2 a terminé de traiter les commandes

En conclusion nous avons vu un exemple simple de l’utilisation de la class LinkedBlockingQueue. Cette classe du package Concurrent de Java 6 offre des fonctionnalités puissantes suffisantes pour répondre à un grand nombre de cas pratiques et réalistes.

N.Martignole et G.Laforge

C’est fait, le premier podcast du Touilleur Express est en ligne sur sa page dédiée. Le premier épisode vous propose d’écouter Guillaume Laforge, le chef de projet du langage Groovy. SpringSource a annoncé le 11 novembre dernier le rachat de sa société, G2One.inc. A l’occasion de la journée « Les Rencontres Spring » nous avons été invité par SFEIR à rencontrer plusieurs personnes de SpringSource. J’ai enregistré une petite interview de guillaume avec Olivier Croisier, auteur du blog « The Coder’s Breakfast« .

Voici des pointeurs vers des sujets abordés dans le podcast :

• article sur InfoQ
• Le Blog de Guillaume
• The eXo Platform
• Benjamin Mestrallet, fondateur d’eXo, gagne le prix du jeune dirigeant de la Technologie

A venir prochainement : interview avec Peter Cooper-Ellis. La qualité n’étant pas assez bonne, je vous proposerai une transcription de notre rencontre avec Peter prochainement.

En attendant voici une photo prise chez SFEIR, avec donc de gauche à droite : Peter Cooper-Ellis, moi-même et enfin Olivier Croisier.

Interview Peter Cooper-Ellis avec Nicolas Martignole et Olivier Croisier