Il est intéressant, dans nombre de cas, de ne charger que partiellement une entité en JPA. Prennons l'exemple de JTentative, un agrégateur de flux RSS. Il est souhaitable de charger la liste des entrées appartenant à un flux, mais sans forcément charger l'intégralité de chaque entité (contenu et description sont des champs lourds et souvent inutilisés).

Plusieurs solutions existent pour charger partiellement une entité, de ne sélectionner que certains champs à charger depuis la base de données.

Première solution : FetchType.LAZY

La première solution consiste à définir certains champs de notre entité avec un attribut fetch à LAZY. Cela permet de spécifier que ces champs ne sont pas chargés lors du chargement de l'entité, mais uniquement lors du premier accès à ce champ.

L'annotation @Basic nous permet de spécifier ce lazy-loading.

Voici un exemple de code mettant en avant cette annotation. Le code de l'entité à été réduit pour plus de lisibilité :

@Entity
public class Entry implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String title;

    private String author;

    @Lob
    @Basic(fetch=FetchType.LAZY)
    private String description;

    @Lob
    @Basic(fetch=FetchType.LAZY)
    private String content;

    /* Getters, Setters... */
}

Cette solution présente cependant un inconvénient majeur : si elle fonctionne correctement lorsque l'on charge une entité via l'EntityManager, elle est complètement inefficace lors de la sélection de données via une requête JPA-QL.

Seconde solution : Sélectionner uniquement les champs dont on a besoin

Une seconde solution peut-être mise en place dans une requête JPA-QL. Cependant, elle ne fonctionnera paslors de la sélection lors d'un appel à la méthode find() de l'EntityManager.

Cette solution est basée sur un opérateur méconnu du langage JPA-QL, new. L'opérateur new permet d'intancier des objets au sein d'une requête JPA-QL. Il s'agit donc d'instancier un objet, en fournissant au constructeur uniquement les champs que nous souhaitons récupérer.

Voici un autre exemple, le code de l'entité a là aussi été réduit :

@Entity
@NamedQuery(name="Entry.findAll", query="SELECT new Entry(e.id, e.title, e.author) FROM Entry AS e")
public class Entry implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String title;

    private String author;

    @Lob
    @Basic(fetch=FetchType.LAZY)
    private String description;

    @Lob
    @Basic(fetch=FetchType.LAZY)
    private String content;

    public Entry() {
    }

    public Entry(Long id, String title, String author) {
        this.id = id;
        this.title = title;
        this.author = author;
    }

    /* Getters, Setters... */
}

Quelques précisions cependant :

• Il faut préciser la classe complète de l'entité dans la requête, incluant le nom du package
• Le constructeur que l'on souhaite invoquer doit exister
• Prennez garde avec vos entités chargées de cette manière : certaines propriétés sont absentes, une mise à jour dans la base de données avec une entité chargée partiellement risque d'effacer certaines valeurs

Le code complet de l'entité utilisée pour cette exemple est disponible sur le dépôt SVN de JTentative.

Cela va mainteant faire 4 jours que GlassFish v3 prelude est sorti. Pour accompagner sa sortie, une vingtaine de présentations ont été faites sur GlassFish (via la chaine TheAquarium, sur Ustream.TV), mais aussi sur Java EE 6 et NetBeans 6.5.

Je viens d'en regarder quelques unes, et celle qui a le plus retenu mon attention est sans aucun doute la présentation des EJB 3.1, qui vient avec son lot d'améliorations et de nouvelles fonctionnalités qui méritent de s'y attarder :-)

On retrouve parmis ces fonctionnalités :

• Les singletons
• Une meilleure gestion des timers
• Les noms JNDI globaux
• Les Session Beans "sans interface"

Les singletons

Les singletons sont des beans qui ont la particularité de n'être instanciés qu'une seule et unique fois tout au long de la vie de notre application. Cette instance sera ensuite partagée entre les différents clients l'utilisant.

@Singleton
public class MySingleton {

    private int sharedValue;

    public int getSharedValue() {
        return (sharedValue);
    }

}

Dans cet exemple de code, notre bean MySingleton sera instancié une seule et unique fois, et chaque appel de méthode fera appel à la même instance, ce qui nous permettra, par exemple, de partager des données (comme la variable sharedValue de notre exemple).

Une meilleure gestion des timers

EJB 3.1 introduit également une nouvelle gestion des timers, qui se rapproche de la gestions des crons Unix : on peut spécifier des tâches à exécuter de manière très précise. Ces timers seront alors automatiquement créés et démarrés.

Voici un exemple, lançant une tâche tous les jours à 8 heures :

@Stateless
public class MyBean implements MyInterface {

    @Schedule(hour="8")
    void myTask() {
    }

}

Les noms JNDI globaux

Il s'agit sûrement d'une des plus grosses lacunes de la spécification EJB 3 qui se trouve ici comblée : l'absence de standardisation des noms JNDI associés aux Session Bean, ce qui entraînait des pertes de portabilité entre les différents serveurs d'application.

Par exemple, sous GlassFish, le nom par défaut d'un Session Bean est le nom complet de l'interface métier de notre bean (com.aperigeek.ejb.MyInterface). Sous JBoss, le nom est <nom du jar>/<nom du bean>/<visibilité>, ce qui donnerais par exemple aperigeek/MyBean/remote. Les noms sont donc très dépendants du serveur d'application.

La nouvelle spécification EJB 3.1 spécifie des noms standards à respecter lors du binding des beans : java:global[/<app-name>]/<module-name>/<ejb-name>, ce qui pourrait donner : java:global/aperigeek/aperigeek-ejb/MyBean. Cette fonctionnalité permet d'assurer la portabilité d'une application entre différents serveurs d'applications.

Les Session Beans "sans interface"

Dernière fonctionnalité dans la série des simplifications de la spécification : la possibilité de définir un Session Bean dans une seule classe, sans passer par une interface métier exposant les différentes méthodes.

@Stateless
public class MyBean {

    public void myMethod() {
    }

}

Dans ce cas de figure, toutes les méthodes publiques deviennent visibles.

@Stateless
public class MyOtherBean {

    @EJB
    private MyBean myBean;

    public void myOtherMethod() {
        myBean.myMethod();
    }

}

La nouvelle version des EJB, la version 3.1, apporte encore quelques améliorations à la version 3.0. L'optique de cette nouvelle version reste essentiellement la même : simplifier l'utilisation des EJBs. On retrouve quand même quelques nouvelles fonctionnalités intéressantes, comme les singletons ou les timers.

Toutes ces nouvelles fonctionnalités sont d'ores et déjà testables grâce à GlassFish v3 prelude, qui sert d'implémentation de référence à cette spécification.