viv's blog

Charger partiellement une entité avec JPA

Vivien Barousse — Fri, 21 Aug 2009 17:24:13 +0100

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.

Aperiquiz #4 : Integer equals Integer

Vivien Barousse — Tue, 21 Jul 2009 21:04:06 +0100

Soit le code suivant :

Quel est la valeur de c ?

true
false
Erreur de compilation
Une exception est levée lors de l'exécution

Réponse : (cliquez pour afficher)

En utilisant Java 5 : false.
En utilisant Java 1.4 : Erreur de compilation.

Explication :
Le cas de Java 1.4 est certainement le plus simple à expliquer : nous avons deux objets de type Integer, et il est impossible de comparer des objets avec les opérateurs < et >. En Java 1.4, l'autoboxing n'existe pas.

Concernant Java 5, l'explication est plus profonde. Nos objets de type Integer sont automatiquement transformés en int dès que nécessaire. C'est le cas lors des comparaisons en utilisant les opérateurs < et >. Ces deux comparaisons renvoient donc false. Cependant, lors de la comparaison avec l'opérateur ==, nos objets ne sont pas convertis en int, mais leur références sont comparées. a et b étant deux objets distincts, la comparaison avec == renvoie false. D'où la valeur de c.

Types primitifs : pièges courants

Vivien Barousse — Wed, 8 Jul 2009 20:21:48 +0100

It's a trap

Je viens de tomber dans la soirée sur deux pièges, non triviaux, mais facile à éviter pour peu de les connaître...

27/10 != 2.7

Le premier bout de code ressemblait à celui-ci :

public class Main {

    public static void main(String... args) {
        float price = 27/10;
        System.out.println("Price: " + price);
    }

}

Alors qu'il est facile de penser que le code suivant va afficher "Price: 2.70" lors de l'exécution, la réalité est tout autre. Effectivement, le résultat une fois ce code compilé / exécuté est "Price: 2.00".

Le piège est le suivant :

27 est, en Java, un entier
10 est, toujours en Java, un entier
L'opération 27/10 est la division de deux entiers. Pour la JVM, le résultat est donc un entier. Donc 2.
La valeur 2 est assignée à une variagle de type float, la valeur 2 est transformée en 2.00
La valeur 2.00 est affichée dans la console.

Il est facile de contourner ce problème : transformer notre division d'entier en division de nombre flottants :

public class Main {

    public static void main(String... args) {
        float price = 27.0/10.0;
        System.out.println("Price: " + price);
    }

}

Dans ce bloc de code, 27.0 et 10.0 sont des nombres à virgule flottante. La division des deux donne une nombre à virgule flottante, donc 2.7. Et le résultat est donc celui attendu.

`return (int) 2.7 - 2.4;`

Le second bloc de code piégé consistait à comparer deux entiers :

public class FloatComparator implements ComparatoréFloat> {

    public int compare(Float f1, Float f2) {
        return (int) (f2 - f1);
    }

}

A première vue, ce code semble lui aussi entièrement correct. Le raisonnement suivi est celui-ci :

Si je renvoie le résultat de f2 - f1, mon objet triera des nombres par ordre croissant
La méthode compare doit renvoyer un entier
Je caste le résultat de ma soustraction (un float) en int.

Ce code fonctionne presque tout le temps. Le problème tiens dans le presque... Pour comprendre où est le problème, rien ne vaut une simulation :

Je souhaite comparer 2.7 et 2.8
2.8 - 2.7 renvoie 0.1, un nombre positif, donc je respecte le contrat de la méthode compare
0.1 est casté en int, le résultat est 0 alors que f2 est suppérieur a f1, je ne respecte plus le contrat de ma méthode

L'erreur se trouve dans le cast. Il faut donc effectuer un changement dans notre méthode pour renvoyer un nombre positif dans tous les cas où f2 est suppérieur à f1. Par exemple :

public class FloatComparator implements ComparatoréFloat> {

    public int compare(Float f1, Float f2) {
        if (f2 > f1) {
            return 1;
        }
        if (f1 < f2) {
            return -1;
        }
        return 0;
    }

}

Le contrat de Comparator est maintenant respecté.

Aperiquiz #3 : Paramètres de méthodes

Vivien Barousse — Tue, 17 Feb 2009 14:10:33 +0100

Quel est le nombre maximum de paramètres pour une méthode ?

127
255
256
Il n'y a pas de limites
Cela dépends du compilateur

Réponse : (cliquez pour afficher)

NetBeans tip : replier un bloc de code

Vivien Barousse — Wed, 11 Feb 2009 17:05:33 +0100

Question assez récurente lorsque des utilisateurs venant d'environnement .NET découvrent NetBeans :

Est-ce qu'il est possible de réduire un bloc de code dans une classe, comme le fait Visual Studio avec ses régions ?

La réponse est oui. cette fonctionnalité de NetBeans est basée sur une balise XML placée dans des commentaires, la balise <editor-fold>.

Petit exemple :
Il est maintenant possible de replier ce bout de code sur lui même, et il sera remplacé par le texte ....

Il est possible de configurer le texte qui sera affiché lorsque le bloc de code sera replié (au lieu de ...). Pour cela, il suffit de spécifier l'attribut desc dans la balise <editor-fold> :

Aperiquiz #2 : Exception générique

Vivien Barousse — Mon, 2 Feb 2009 18:44:21 +0100

Est-ce que le code suivant compile ? Réponse : (cliquez pour afficher)

Non.

Explication :
La spécification du langage précise explicitement : "It is a compile-time error if a generic class is a direct or indirect subclass of Throwable." (Traduction : "C'est une erreur de compilation si une classe générique hérite directement ou indirectement de Throwable").

En effet, le mécanisme de catch des exceptions en Java ne fonctionne qu'avec des classes non génériques. C'est pour cela que les classes héritant de Throwable ne peuvent pas être typées avec des generics.

Sources :

Java Language Specification, §8.1.2

Aperiquiz #1 : Finally returns

Vivien Barousse — Mon, 26 Jan 2009 14:06:29 +0100

Ceci est le premier post d'une longue (j'espère) série de questions : l'Aperiquiz.

Le principe est simple : mettre en évidence un point précis de la spécification Java en se basant sur un exemple de code inhabituel, une question tordue ou une particularité peu connue du langage.

Prêts ? C'est parti !

Considérant le code suivant :

public class Main {

    public static String myMethod() {
        try {
            return "try";
        } catch (Exception e) {
            return "catch";
        } finally {
            return "finally";
        }
    }

    public static void main(String[] args) {
        System.out.println(myMethod());
    }

}

Quel est le résultat ?

try
catch
finally

Réponse : (cliquez pour afficher)

finally

Sources :

Stack Overflow : Questions to indicate competency in Java (merci à Martin pour le lien)

Comment se débarasser de com.sun.messaging.jmq.io.Packet cannot be cast to com.sun.messaging.jms.ra.DirectPacket ?

Vivien Barousse — Fri, 16 Jan 2009 16:51:31 +0100

Avec une installation par défaut de GlassFish, l'utilisation de JMS au sein du serveur d'application amène souvent à l'erreur suivante :


DirectConsumer:Caught Exception delivering messagecom.sun.messaging.jmq.io.Packet cannot be cast to com.sun.messaging.jms.ra.DirectPacket

Cette erreur n'est pas fatale, l'application est tout de même déployée et les différents messages sont envoyés et reçus. Cependant, cette erreur est générée à chaque envoi de message, ce qui peut rapidement devenir encombrant dans les fichiers de log de GlassFish.

Cette exception viens du mode de configuration utilisé pour le lancement du service JMS dans GlassFish. Par défaut, le service est lancé en mode EMBEDDED. Le service JMS tourne dans le même processus que le serveur GlassFish, ce qui provoque ce genre d'erreurs.

Il est possible de changer ce mode de lancement du service JMS. Il suffit de lancer ce même service en mode LOCAL pour que le service tourne dans un processus séparé du serveur GlassFish (mais toujours sur la même machine). Le service JMS sera toujours contrôlé par GlassFish (lancement simultanés entre autre). Changer ce mode de fonctionnement du service JMS permet de résoudre ce problème de cast de messages.

Pour effectuer ce changement, il faut se rendre dans la console d'administration de GlassFish :

Accéder à l'adresse http://localhost:4848/
Se connecter avec les identifiants d'administration de GlassFish (par défaut : admin /// adminadmin)
Cliquer sur "Configuration" -> "Java Message Service" dans le menu de navigation de gauche
Modifier la propriété "Type" et lui donner la valeur de "LOCAL"

RichFaces : Filtrer et trier une DataTable

Vivien Barousse — Sat, 29 Nov 2008 17:18:40 +0100

Après avoir installé RichFaces, je me suis lancé dans la rédaction d'une page d'exemple, histoire d'apprendre le fonctionnement de cette librairie qui semble bien intéressante.

Le but de cette page d'exemple est de mettre en place une DataTable, avec fonctionnalités de tri et de filtres. Toutes ces fonctionnalités utiliseront de l'Ajax, et il ne sera donc pas nécéssaire de recharger la page afin de voir les changements.

Les contacts contenus dans notre DataTable devront être triés par nom de famille par défaut. Il sera également possible pour l'utilisateur de changer l'ordre de tri (croissant, décroissant), ainsi que la propriété servant à effectuer ce tri (prénom, nom, ou adresse mail).

Enfin, pour le filtre, nous aurons un champ de texte qui limitera la liste aux contacts :

Dont le nom commence par la requête
Dont le prénom commence par la requête
Dont l'adresse mail contient la requête

Mise en place d'une Rich DataTable

Afin de commencer notre page d'exemple, nous allons créer une classe Contact, qui aura pour vocation de contenir les données. Cette classe est un JavaBean, et possède donc les caractérisques suivantes :

Les propriétés doivent être privées
Chaque propriété doit avoir des accésseurs (getters et setters) publics
La classe doit avoir un constructeur par défaut
La classe doit implémenter Serializable

Nous allons donc créer notre classe Contact avec les propriétés firstName, lastName et mailAddress :

La seconde étape sera de créer un managed bean JSF, qui nous renvera une liste de contacts d'exemple :

Et enfin, dernière étape, nous allons créer notre Rich DataTable, basique pour l'instant, capable d'afficher ces données :

Nous avons dans l'exemple de code précédent créé une Rich DataTable. Le code ressemble à celui d'une DataTable classique, la seule différence étant l'utilisation de la taglib RichFaces au lieu de la taglib standard.

Rajout des fonctionnalités de tri

L'ajout du tri dans une Rich DataTable est très facile. La balise <rich:column /> possède un attribut sortBy, qui permet de spécifier la propriété qui sera utilisée pour trier la colonne concernée.

Notre code précédent ressemble donc désormais à ceci :
L'exécution de ce code nous montre que sur chaque colonne, RichFaces a rajouté des boutons permettant à l'utilisateur de choisir quelle colonne sera utilisée pour trier les données, et de choisir l'ordre de tri.

Il est également possible de donner un ordre de tri par défaut à notre DataTable. Pour celà, nous allons utiliser l'attribut sortOrder de notre balise <rich:column /> :
Ainsi, au lancement de la page, les contacts seront triés par ordre alphabétique en fonction de leur nom de famille. Il sera également possible pour l'utilisateur de changer la propriété servant à faire le tri (et de choisir le prénom, ou l'adresse mail). L'utilisateur aura également la possibilité de changer l'ordre de tri (croissant, décroissant).

Filtrer les données

Le filtrage des données à l'intérieur d'une DataTable passe par plusieurs étapes :

Il faut commencer par créer un champ de texte, permettant à l'utilisateur de rentrer la requête sur laquelle nous allons nous baser pour filtrer les entrées
Il faudra ensuite créer une méthode permettant de filter chacune de nos entrées. Cette méthode prends en paramètre l'objet à filter, et renvoie un booléen indiquant si l'objet doit être affiché
Enfin, il faudra que notre DataTable soit mise à jour à chaque modification de la requête

La première étape est donc de créer notre champ de texte. Il s'agit d'un simple champ de texte JSF (<h:inputText />) que nous allons lier à une propriété d'un managed bean : Puis le code JSP correspondant :
Seconde étape, toujours dans notre managed bean, nous allons créer une méthode filtrant les objets de type Contact en fonction de la requête qui nous est envoyée par le champ de saisie. Dans l'exemple ci dessous, la méthode doFilter prends en paramètre l'objet que nous allons devoir filtrer (dans notre cas, on objet de type Contact), et dois renvoyer true si le contact doit être affiché, false sinon : Nous allons également dire à notre DataTable d'utiliser cette méthode afin de filtrer les entrées à afficher :
Enfin, dernière étape, nous allons préciser à RichFaces que notre champ de texte doit automatiquement rafraîchir, en Ajax, notre DataTable afin que les données soient de nouveau filtrées, avec la nouvelle requête : La balise <a4j:support /> permet, entre autres, de mettre rafraîchir un composant. Elle prends 3 paramètres :

event : l'évènement JavaScript qui devra déclencher le rafraîchissement
reRender : le composant à rafraîchir
requestDelay : permet de spécifier un délai entre la requête et le refraîchissement du composant

A chaque fois que la valeur du champ de texte est modifiée, la nouvelle valeur est envoyé dans notre managed bean, et notre DataTable est raffraîchie. Ainsi, le tableau va de nouveau être filtré, et notre méthode va permettre d'éliminer certains résultats de notre tableau.

Nous avons donc vu un premier exemple de fonctionnalité Ajax qu'il est possible de réaliser grâce à RichFaces. Une DataTable avec fonctionnalités de tri et de filtre, qui se rafraîchit sans recharger la page.

Les sources du projet NetBeans de cet article sont disponnibles ici.

RichFaces

Vivien Barousse — Wed, 26 Nov 2008 19:12:04 +0100

Je continue dans ma recherche de librairie de composants pour JSF. J'avais déjà testé ICEFaces, mais elle ne me satisfaisait pas. Trop de changement au niveau du cycle de vie de JSF à mon goût.

J'ai testé aujourd'hui une nouvelle librairie, qui à l'air de s'intégrer parfaitement à JSF. Très peu de changements dans le cycle de vie JSF, beaucoup de composants, dont la plupart en Ajax. Il s'agit de RichFaces.

L'installation, comparée à celle de ICEFaces, est très simple. Quelques librairies, quelques dépendances (BeanUtils, Collections, Digester, Commons Log). La seule configuration nécessaire est la déclaration d'un filtre dans le fichier web.xml :
Il ne reste plus qu'à tester la liste assez imposante de composants proposés :)

NetBeans 6.5 est parmis nous

Vivien Barousse — Wed, 19 Nov 2008 18:29:12 +0100

La version 6.5 de l'IDE NetBeans viens de sortir, en version finale.

Après téléchargement et installation, la première impression est assez marquante. Le lancement est encore plus rapide, et l'interface encore plus fluide (comparé à la version 6.1).

Au niveau des nouvelles fonctionnalités, quelques nouveautés assez importantes :

Environnement de développement PHP (et une distribution de NetBeans spécialisée)
Amélioration du support Java EE (notamment JSF et JPA)
Éditeur Java FX
Support de GlassFish v3 prelude, uniquement pour de développement Web
Amélioration de l'éditeur Java
Nouvelles fonctionnalités dans l'IDE de base

Compile on save / Deploy on save
Modification des préférences d'indentation par projet
Barre de recherche rapide

La liste complète est disponible ici.

Parmis ces fonctionnalités, certaines me plaisent déjà, dont :

Le "compile/deploy on save" qui recompile et/ou redéploie un projet dès qu'un changement est fait dans un fichier
Le support de GlassFish v3 prelude (que j'aime déjà, pour sa rapidité, et ses derniers frameworks [EJB 3.1, JSF 2.0])
Les préférences d'indentation spécifique à chaque projet. Finies les guerres d'indentation sur les dépots !

Il y a aussi quelques fonctionnalités qui restent à tester et qui semblent intéressantes, comme le support amélioré de JSF et de JPA.

Pour les téléchargements, c'est directement ici.

EJB 3.1, on y arrive !

Vivien Barousse — Tue, 11 Nov 2008 16:34:36 +0100

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.

Java/C : Sockets

Vivien Barousse — Fri, 3 Oct 2008 08:28:09 +0100

J'ai refait un peu de C hier, "pour le plaisir"... Je pense que les deux bouts de code au dessus parlent pour moi :-)

Juste, en passant, le plugin C/C++ de NetBeans est tout simplement... bien. Toutes les fonctionnalités que l'on attend d'un IDE sont là (autocomplétion, affichage des paramètres des fonctions, ...). Moi qui n'aimais pas les IDE pour le C, j'ai été plutôt surpris. Dans le bon sens :-)

Java/.NET : Opérateurs

Vivien Barousse — Thu, 2 Oct 2008 12:43:46 +0100

Dans ce billet, nous allons parler des opérateurs. Les opérateurs existants en Java existent également en C#, et les différences entre les deux sont quasi-inexistantes.

Nous allons donc parler de deux fonctionnalités, présentes en C#, qui n'existent pas en Java :

La surcharge des opérateurs
Les indexeurs

Surcharge des opérateurs

Le langage C#, contrairement au langage Java, implémente la surcharge des opérateurs. Les principes sont inspirés du C++.

Voici un exemple de surcharge des opérateurs en C# :

class Program
{
    static void Main(string[] args)
    {
        MyString s1 = new MyString("Hello ");
        MyString s2 = new MyString("World!");
        MyString s = s1 + s2;
    }
}

class MyString
{
    private string _value;
    public MyString(string _value)
    {
        this._value = _value;
    }
    public static MyString operator + (MyString a, MyString b)
    {
        return (new MyString(a._value + b._value));
    }
}

Il n'existe aucun équivalent à la surcharge des opérateurs en Java.

Indexeurs

Le langage C# introduit un nouveau concept, les indexeurs. Un indexeur est semblable à un opérateur, et il permet d'accéder à un index donné d'un objet, comme par exemple un tableau. Cet index peut être de type int, mais aussi de n'importe quel autre type, valeur ou référence.

Voici un exemple de code mettant en oeuvre un indexeur :

class Program
{
    static void Main(string[] args)
    {
        MyIndex i = new MyIndex();
        Console.WriteLine(i[12]);
    }
}

class MyIndex
{
    public string this [int index]
    {
        get
        {
            return ("Index " + index);
        }
    }
}

Il n'existe aucun équivalent aux indexeurs en Java.

En ce qui concerne les opérateurs en C#, nous avons vu deux fonctionnalités intéressantes qui n'existent malheureusement pas en Java.

Beaucoup de personnes ont espéré voir la surcharge des opérateurs arriver dans Java 7. Cependant, cette fonctionnalités est assez controversée, et il y a peu de chances de la voir arriver dans le langage (de même que les indexeurs).

Neal Gafter quitte Google... Pour Microsoft

Vivien Barousse — Tue, 30 Sep 2008 09:40:25 +0100

Les rumeurs courent depuis plusieurs jours maintenant, et c'est maintenant certain. Neal Gafter, un des "grands" du monde Java, viens de quitter Google pour aller travailler chez Microsoft.

Neal Gafter travaille depuis longtemps pour le monde Java. Il a notamment dirigé les évolutions du langages et des outils (java, javac, javah et javap) de la version 1.3.1 à la version 1.5.0 du JDK. Plus récemment, il a également contribué à Java 7, et fait entre autres partie de l'équipe à l'origine des closures BGGA.

Maintenant chez Microsoft, il travaille sur les langages de la plate-forme .NET, et en particulier le langage C#.

Beaucoup en parlent comme d'une mauvaise nouvelle pour le monde Java, il reste à voir ce que ce changement va nous apporter...

Java/.NET : Types de données

Vivien Barousse — Mon, 29 Sep 2008 06:55:15 +0100

Dans ce second billet de la série "Java/.NET", nous allons parler de toutes les différences touchant aux types de données.

Fichiers sources

En Java, le compilateur n’autorise qu’une seule et unique classe publique par fichier source. De plus, la classe publique d’un fichier source doit posséder exactement le même nom que le fichier dans lequel elle se trouve.

En C#, les restrictions comme celles-ci n’existent pas. Il est possible de déclarer plusieurs classes publiques au sein du même fichier, et aucune vérification n’est faite quand au nom du fichier contenant les classes.

Types primitifs - types valeurs

En Java comme en C#, il existe un type de données particulier : leur valeur est directement stocké dans une zone mémoire appelée la pile. De plus, ces différents types de données sont directement passés par valeur.

Ils peuvent représenter une valeur "basique", à savoir :

Un nombre (entier ou à virgule flottante)
Un caractère
Un booléen

En Java, ces types de données qui sont appelés des types primitifs. Il s’agit des seuls types de données qui ne sont pas des objets, c'est-à-dire qu’ils ne possèdent aucune méthode. Pour palier à cet inconvénient, il existe des types dits wrappers, qui sont des équivalents objets de ces types primitifs.

En C#, ces types sont appelés les types valeurs. Ils résident également sur la pile, mais ce sont cependant des objets. Chaque type valeur possède un alias, qui permet de faciliter l’appel de ces types dans le code. Par exemple, le type valeur Int32 possède un alias int. Ces alias seront convertis au moment de la compilation.

A noter également qu’en C#, les chaînes de caractères et les énumérations ont la particularité d’être des types valeur. Au contraire, les chaînes de caractères et les énumérations en Java sont des objets, et résident sur le tas.

Types références

Chacun des deux langages définit un autre type de variables : les types références.

Contrairement aux types primitifs (ou types valeurs), ils sont passés par référence lors des différents appels de méthodes. Ils représentent en général des types complexes, que nous allons définir nous même. De plus, la valeur de ces types de données est stockée sur le tas, et la pile ne contient qu’une référence vers ces objets.

En Java, chaque type primitif possède un équivalent en type référence. Ce sont les types wrappers. Ces objets sont des objets comme tous les autres objets Java. Leur valeur réside sur le tas et ils sont passés par référence lors des différents appels de méthodes. Depuis Java 1.5, la conversion entre les types primitifs et types wrapper est automatique.

En C# comme en Java, les classes sont des types références.

Structures

Le langage C# introduit un type de données qui n’existe pas en Java : le type structure. Les structures sont un type de données semblable aux classes, sauf qu’elles sont de types valeur, et non de type référence.

Cette différence implique que les structures sont stockées sur la pile (et non sur le tas, contrairement aux objets), et qu’elles sont passées par valeur en paramètre aux méthodes.

De par leur statut particulier, les structures ont cependant quelques fonctionnalités en moins par rapport aux classes. Il est impossible par exemple d’hériter d’une structure en C#.

Enumérations

En Java, les énumérations sont des objets. Comme pour les objets, il est possible de leur définir des attributs, des méthodes, et même des constructeurs.

Contrairement à cela, en C#, les énumérations sont de type valeur. Les énumérations correspondent à des entiers codés sur 8, 16, 32 ou 64 bits. Il est également possible d’assigner n’importe quelle valeur numérique à une énumération (y compris des valeurs non définies dans l’énumération), ainsi que de combiner plusieurs valeurs pour une même énumération grâce à l’opérateur | (bitwise or).

Espaces de nommages

Lors du développement d’applications, il arrive que plusieurs structures de données (classes, interfaces, énumérations...) possèdent le même nom. Afin d’éviter les collisions de noms ainsi générées, chaque langage à mis en place sa propre solution : les espaces de nommages.

En Java, un espace de nommage s’appelle un package. Un package doit être déclaré en début de tout fichier source grâce au mot clé package suivi du nom du package, et s’applique à tout le fichier. Il est possible d’accéder à des classes appartenant à d’autres packages grâce au mot clé import, suivi du nom de la classe à importer. Il est également possible d’importer toutes les classes d’un package en utilisant l’étoile (*).

En C#, un espace de nommage s’appelle un namespace. Un namespace est un bloc de code, noté grâce au mot clé namespace, suivi du nom du namespace. Il est possible d’utiliser des classes appartenant à d’autres espaces de noms grâce au mot clé using, suivi du nom de l’espace de nom à utiliser.

Voici par exemple la déclaration de deux classes dans un espace de nommage, en Java (à gauche) et en C# (à droite) :

package ns;

class Toto {
}

class Tata {
}

namespace Ns
{
    class Toto
    {
    }
    class Tata
    {
    }
}

Types génériques

Java et C# implémentent tous les deux les types génériques. Si l’utilisation est similaire dans les deux langages, leurs implémentations sont cependant très différentes.

Premier point, les types génériques en Java n’acceptent pas les types primitifs, alors que l’implémentation en C# accepte les types valeurs.

Second point, les génériques en Java sont implémentés selon une technique dite du type erasure. Derrière ce nom effrayant se cache un concept simple : les génériques en Java sont évalués à la compilation, toute trace de type générique n’existe plus à l’exécution. C’est le compilateur qui va se charger de transformer les types génériques en leurs opérations équivalentes (principalement du transtypage et des vérifications de types), et supprimer toute trace de leur passage.

Contrairement à cela, les génériques en C# persistent à l’exécution, et sont interprétés par l’environnement d’exécution. Il est donc possible de connaître le type générique d’une classe ou d’une méthode lors de l’exécution.

Les conséquences sont alors multiples. Par exemple, en C#, il est possible de créer une instance d’un type générique, et des tableaux de types génériques, choses qui sont impossibles à faire en Java, principalement à cause du type erasure.

Autre différence importante, il est possible d’effectuer des vérifications plus poussées sur les types utilisés en tant que types génériques dans le langage C#. Par exemple, en C#, il est possible de définir une contrainte « Cette classe utilise un type T, qui doit posséder un constructeur par défaut », contrainte qui est impossible en Java.

Voilà donc la fin de cette liste de différences entre Java et C# en ce qui concerne les types de données.

Le prochain billet portera sur les opérateurs, et devrait parler de deux fonctionnalités présentes en C# et inexistantes en Java : la surcharge des opérateurs et les indexeurs.

PS : Ceci était de 42ème billet de ce blog ;-)

Java/.NET : Concepts élémentaires

Vivien Barousse — Mon, 22 Sep 2008 08:33:23 +0100

Dans ce premier billet de la série consacrée aux différences entre Java et .NET, nous allons voir les concepts élémentaires des deux plateformes.

Les concepts élémentaires au niveau des deux technologies sont très similaires. Les deux s’appuient sur le même principe : la compilation est effectuée vers un langage intermédiaire. Ce langage intermédiaire est proche du langage machine, mais indépendant de l’architecture et du système. Il sera ensuite exécuté par une machine virtuelle au moment de l’exécution du programme. Ce principe permet d’assurer une certaine portabilité entre les différents systèmes d’exploitation et les différentes architectures matérielles.

Compilation

Le compilateur C# s’appelle CSC (C-Sharp Compiler). Il est chargé de traduire le code source C# en code MSIL (Microsoft Intermediate Language), un langage intermédiaire qui sera ensuite exécuté par l’environnement d’exécution de la plateforme .NET.

Le compilateur Java est appelé Javac (Java Compiler), et son rôle est de transformer le code source Java en ByteCode, qui est le langage intermédiaire de la plateforme Java.

Les deux compilateurs comportent également des fonctionnalités plus poussées. Chacun des compilateurs est capable, par exemple, d’optimiser le code source au moment de la compilation afin d’en améliorer les performances. Il n’y a pas de différence majeure à ce niveau là.

Environnement d'exécution

L’environnement d’exécution .NET est construit autour de la CLR (Common Language Runtime). Il s’agit de la machine virtuelle chargée d’exécuter le code MSIL généré par le compilateur.

De son coté, l’environnement d’exécution Java tourne autour de la JVM (Java Virtual Machine). Son rôle sera d’exécuter le ByteCode, afin de permettre l’exécution de nos programmes.

Les deux machines virtuelles sont très proches, et sont conçues de manière semblable. Les deux embarquent un chargeur de classe (Class Loader), un compilateur JIT (Just In Time) qui transforme le code intermédiaire en code natif afin d’accélérer l’exécution, d’un ramasse miettes (Garbage Collector) qui libère la mémoire qui n’est plus utilisée par le programme, ainsi que d’autres composants permettant d’assurer le bon fonctionnement de nos logiciels (sécurité des applications, interaction avec le système, ...).

La principale différence au niveau de l’environnement d’exécution est la portabilité de celui-ci. Alors qu’il existe une machine virtuelle Java pour la plupart des systèmes d’exploitation du marché, la CLR de Microsoft est développée uniquement pour Windows. Même si Microsoft à fait des efforts ces derniers temps pour porter la CLR vers d’autres systèmes (notamment grâce au projet Mono), la plateforme .NET est loin de posséder la même portabilité que la plateforme Java.

Bibliothèques de base

Chacun des deux environnements embarque une bibliothèque de base. Ces bibliothèques sont des ensembles de composants prêts à l’emploi, qui permettent de faciliter le développement d’applications. Sur les deux plateformes, nous retrouvons des composants semblables : interfaces graphiques, gestions des entrées-sorties, gestion de l’accès aux données (bases de données, annuaires LDAP, ...), gestion des processus...

Les principales différences entre les deux ensembles de bibliothèques embarquées se trouvent dans les noms attribués aux classes et aux méthodes, la plupart des composants présents dans l’une trouvant son équivalent dans l’autre.

Ainsi s'achève ce premier billet portant sur les concepts élémentaires de chacune des plateforme. Comme nous l'avons vu, les différences sont assez minimes, et les principes globaux sont communs aux deux environnements.

Dans le prochain billet, nous aborderont les différences qui touchent aux types de données (types primitifs/valeurs, types références, énumérations, ...).

Java/.NET : Introduction

Vivien Barousse — Fri, 12 Sep 2008 18:22:29 +0100

Ça y est !

Je viens de finir une (longue) période de formation. J'ai été invité à suivre une formation de trois semaines, qui s'est terminée aujourd'hui, au SUPINFO Training Center, portant sur les technologies .NET, et en particulier :

Framework .NET 2.0, base du développement d’application
Windows Forms, Accés aux données avec Visual Studio 2005
Création et programmation d’une application Web ASP.NET 2.0

Étant formateur Sun (et donc, Java), le but de cette formation était de comparer les deux technologies. Loin de moi l'idée d'abandonner le Java pour me mettre au .NET (j'ai déjà vendu mon âme :P). Il s'agissait là d'une ouverture d'esprit, de la découverte d'une autre technologie afin de mieux pouvoir défendre la sienne.

La formation en elle-même était très intéressante. Les deux premières semaines (Framework 2.0 et Windows Forms) furent dispensées par Julien Corioland, la dernière par Maxime Schneider (je tiens à les remercier tous les deux). Le seul point noir que j'aurais à souligner concerne le cursus en lui même, qui portait sur le framework 2.0 alors que la version la plus récente est la 3.5, et que les changement entre les deux versions sont importants (WPF, WCF, Linq, ...).

J'ai déjà fait un petit résumé de cette formation en 140 caractères (à la demande de Julien Quéré) :

Il y a quelques fonctionnalités interessantes (properties, delegates, ...), mais mon coeur reste chez Java :-)

Je pense que cette citation est celle qui résume le mieux ce que je pense de ces trois dernières semaines.

Je vais maintenant entamer (continuer serait plus exact, j'ai déjà un peu commencé :P) un gros feedback sur ce que j'ai retenu de cette formation : les principales différences entre Java et .NET.

Ceux qui me connaissent le savent, je suis un excellent trolleur. Et ils n'ont pas complètement tort. Je vais cependant essayer d'être le plus objectif possible :-)

Ce billet est donc le premier d'une série qui relatera les différences que j'ai constaté, retenu, et qui ont, à mon avis, leur importance, pour le développeur qui souhaite comparer les deux plateformes de développement.

Petite remarque au passage : Ce billet était aussi le billet de la rentrée. En effet, je n'avais pas publié de billets, pour des raisons diverses et variées, depuis environ deux mois. La rentrée étant arrivée, mon rythme de publication devrait redevenir un peu plus... soutenu :-)

Rédaction estivale

Vivien Barousse — Tue, 15 Jul 2008 02:34:49 +0100

Une fois n'est pas coutume, je vais parler de moi.

Comme ceux qui me suivent fréquemment ont pu le constater, mon rythme de rédaction s'est énormément ralenti ces derniers temps, principalement depuis le début du mois de juin. Je vais essayer d'en expliquer les raisons et de rassurer certains de mes lecteurs pour la suite. La raison pour laquelle je ne blogue plus beaucoup ces derniers temps est presque évidente.

C'est la fin de l'année scolaire

Les étudiants sont partis en stage, alors que le mien ne commence que début août. Je suis en quelque sorte en vacances. Mon blog est nourri principalement d'échanges avec les gens que je côtoie tous les jours à SUPINFO, avec les élèves. Depuis la fin du mois de juin, le nombre de personnes avec lesquelles je discute "Java" à fortement diminué. D'où une baisse des questions qui nécessitent une réponse. D'où une baisse du nombre d'articles sur ce blog.

Mon stage commence précisément le 4 août. Mon rôle sera de préparer les PEFF (Peut-être futurs formateurs, comme dirait Mauricio) afin qu'ils soient capables de dispenser des cours dès le mois d'octobre. Ce "stage" s'est révélé très intéressant l'an dernier, notamment grâce à une intervention de Alexis Moussine-Pouchkine sur GlassFish. J'espère que celui de cette année le sera tout autant. Entouré de geeks du Java, de geeks tout court, j'espère pouvoir reprendre mes échanges sur le monde Java, pouvoir reprendre plus activement la rédaction de ce blog.

En attendant le début du mois d'août, d'ici deux semaines, je ne bloguerais quasiment pas. Pour ceux qui cherchent désespérément de la lecture, je peux vous conseiller pour l'été :

"EJB 3 - Des concepts à l'écriture du code. Guide du développeur", écrit par le laboratoire Sun (et auquel j'ai participé), chez Dunod. La seconde édition est sortie il y a à peine quelques jours. Je n'en avais pas encore parlé, voilà qui est chose faite.
Java.Blogs. À mon avis un des meilleurs agrégateurs de blogs Java, très utile pour se tenir au courant des tendances actuelles.

NetBeans 6.5 en approche

Vivien Barousse — Tue, 8 Jul 2008 10:03:03 +0100

La blogosphère en parle beaucoup depuis ce matin (ici, là, ou encore là), la première milestone de NetBeans 6.5 est sortie.

L'annonce officielle nous propose un petit aperçu des nouvelles fonctionnalités.

La nouveauté majeure de cette version 6.5 semble l'apparition de l'éditeur PHP (présentation des fonctionnalités, screencast, tutorial). Le blog NetBeans for PHP à également fait son apparition récemment.

D'autres améliorations sont également au programme, notamment en ce qui concerne les éditeurs JavaScript (Ajax), Groovy et Java.

Le meilleur moyen de se faire une idée reste encore et toujours de la tester par soi même. Téléchargement ici.

Changement de serveur

Vivien Barousse — Wed, 2 Jul 2008 23:49:40 +0100

Si vous lisez ces quelques lignes, c'est que je ne me serais planté nulle part. Ou du moins que mes erreurs ne sont pas critiques.

La résiliation de l'abonnement Internet étant en cours, mon blog, qui était jusqu'à présent hébergé chez moi, avait devant lui des jours qui lui étaient comptés.

C'est pour cela que j'ai migré mon installation de Roller vers un nouveau serveur, loué pour l'été (voire plus...) chez OVH (un Kimsufi, qui me suffit pour l'instant).

A première vue tout marche, j'essayerais de réparer les éventuels défauts dans les jours à venir... En attendant, bonne lecture :)

Astuce Java #6 : Enum et toString

Vivien Barousse — Fri, 20 Jun 2008 17:01:03 +0100

Depuis Java 5, le langage Java dispose d'une nouvelle fonctionnalité : les énumérations.

Les énumérations sont des structures permettant de représenter une variable ayant un nombre fini de valeurs, comme par exemple le sexe d'une personne, qui sera soit "homme", soit "femme".

Les énumérations sont mises en place de la manière suivante :

enum Sex {
    MALE,
    FEMALE;
}

Il est ensuite possible de créer des variables du type de l'énumération, et de les utiliser :

Sex sex = Sex.MALE;
System.out.println(sex);

Et c'est là qu'apparaît notre problème : la console nous affiche "MALE". Certes, il s'agit de la bonne valeur, mais la présentation n'est pas très esthétique. Heureusement pour nous, en Java une énumération est également un objet. Il nous est possible de définir nos propres méthodes, et aussi de récrire certaines méthodes de la classe Object. Ainsi, on peut avoir le code suivant :

enum Sex {
    MALE,
    FEMALE;
    
    @Override
    public String toString() {
        switch (this) {
            case MALE:
                return ("Male");
            case FEMALE:
                return ("Female");
        }
        throw new RuntimeException("Invalid value for this");
    }
}

L'exécution du même code nous donne ainsi "Male" au lieu de "MALE". On obtient le résultat souhaité, à savoir une chaîne de caractères plus facilement lisible par l'utilisateur.

Le soucis que l'on rencontre maintenant viens du switch dans la méthode toString. Nous devons gérer toutes les valeurs possible dans cette méthode, sous peine de lancer une RuntimeException. Une des solutions possibles (que j'ai trouvé dans un commentaire d'un (très) vieux billet de blog), et que je trouve de loin ma préférée, est de fournir un constructeur à notre énumération. Ce constructeur prend en paramètre une chaîne de caractères qui sera utilisée en tant que valeur de retour de la méthode toString :

enum Sex {
    MALE("Male"),
    FEMALE("Female");
    
    private String value;
    
    private Sex(String value) {
        this.value = value;
    }
    
    @Override
    public String toString() {
        return (value);
    }
}

Ainsi, nous obtenons on comportement optimal :

Chaque valeur de l'énumération renverra une chaîne de caractères "esthétique" représentant sa valeur
Chaque valeur devra posséder une chaîne de caractères (au risque de générer une erreur de compilation)

Le problème majeur qui est ainsi rencontré concerne la conversion énumération -> chaîne de caractères -> énumération. La chaîne de caractères renvoyait de base par toString était le nom de la constante dans l'énumération (MALE ou FEMALE dans notre cas), qui pouvait ensuite être reconverti en énumération via la méthode valueOf. Dans notre cas, la conversion ne se ferra plus puisque toString ne renverra plus une valeur compréhensible par valueOf. Cependant, la méthode name, définie dans toute énumération, renvoie toujours le nom de la constante tel que définit dans le code.

Système d'inclusion en JSF

Vivien Barousse — Fri, 6 Jun 2008 14:55:25 +0100

Pour éviter les erreurs, voici un rapide rappel pour faire de l'inclusion de pages en JSF. Cet article contient un exemple de code classique, puis quelques points à ne pas oublier pour que tout se passe bien.

Le but de cet exemple sera d'avoir une page index.jsp qui inclue une page content.jsp.

`index.jsp`

<%@page contentType="text/html"%>
<%@page pageEncoding="UTF-8"%>

<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <title>JSP Page</title>
    </head>
    <body>
        <f:view>
            <f:subview id="content">
                <jsp:include page="content.jsp" flush="false" />
            </f:subview>
        </f:view>
    </body>
</html>

`content.jsp`

<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>

<h:outputText value="Ceci est le contenu !" />

Points importants

Il existe quelques règles assez importantes pour que ce système d'inclusion de page marche correctement :

Dans la page de base, entourer l'inclusion avec une balise <f:subview />
Lors de l'inclusion, penser à mettre l'attribut flush à false. Cet attribut existe sur la plupart des balises permettant l'inclusion de pages.
Dans la page de destination, réutiliser les composants JSF directement, sans remettre de balise <f:view />
Les taglibs doivent quand à elles être réimportées.

Et voilà le résultat (en HTML) :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <title>JSP Page</title>
    </head>

    <body>
        Ceci est le contenu !
    </body>
</html>

Martin en parle également.

Optimisation : Utilisation d'un pool d'objets

Vivien Barousse — Sat, 31 May 2008 20:30:11 +0100

J'ai lu récemment une série d'articles^{1 2 3 4} très intéressants ayant pour sujet l'optimisation des programmes Java. La dernière partie parlait de la réutilisation des objets. Un exemple montrait qu'il était plus performant de vider un ArrayList que de créer une nouvelle instance :

for (int i = 0; i < 10; i++) {
    ArrayList list = new ArrayList();
    // Do some stuff...
}

ArrayList list = new ArrayList();
for (int i = 0; i < 10; i++) {
    // Do some stuff...
    list.clear();
}

Dans notre cas, appeler un constructeur est plus coûteux en temps processeur que de simplement supprimer tous les éléments de notre liste (la raison a été discutée sur comp.lang.java.programmer). Le code de droite est donc plus rapide à l'exécution.

J'ai alors eu l'idée de me lancer dans la création d'un pool d'objets. Dans le cas des ArrayList, le but serait de vider notre instance et de la conserver en attendant de la réutiliser plus tard.

J'ai donc testé le code suivant :

public class ArrayListPool<T> {

    private Queue<ArrayList<T>> pool;
    
    public ArrayListPool() {
        pool = new LinkedList<ArrayList<T>>();
    }
    
    public ArrayList<T> getArrayList() {
        synchronized (pool) {
            if (!pool.isEmpty()) {
                return (pool.poll());
            }
        }
        return (new ArrayList<T>());
    }
    
    public void releaseArrayList(ArrayList<T> list) {
        list.clear();
        synchronized (pool) {
            pool.offer(list);
        }
    }
    
    public void clear() {
        synchronized (pool) {
            pool.clear();
        }
    }
}

Le but est d'appeler getArrayList pour obtenir une instance d'un ArrayList, et de la passer en paramètre à la méthode releaseArrayList pour la remettre dans le pool et la réutiliser au besoin.

Concernant les détails de fonctionnement, je me suis servi d'une LinkedList pour stocker les objets à réutiliser. Cette implémentation de Queue est basée sur une liste chaînée, ainsi les insertion et les suppressions d'éléments dans le pool sont très rapides.

Enfin, l'utilisation de ce pool. À gauche, le code de base, qui servira de benchmark par la suite. À droite, le code modifié pour utiliser le pool.

ThreadGroup group2 = new ThreadGroup("Group 2");
for (int i = 0; i < threadCount; i++) {
    Thread t = new Thread(group2, "Thread " + i) {
        @Override
        public void run() {
            for (int i = 0; i < listCount; i++) {
                ArrayList<Object> list = new ArrayList<Object>();
                for (int j = 0; j < objectCount; j++) {
                    list.add(new Object());
                }
            }
        }
    };
    t.start();
}

final ArrayListPool<Object> pool = new ArrayListPool<Object>();
ThreadGroup group1 = new ThreadGroup("Group 1");
for (int i = 0; i < threadCount; i++) {
    Thread t = new Thread(group1, "Thread " + i) {
        @Override
        public void run() {
            for (int i = 0; i < listCount; i++) {
                ArrayList<Object> list = pool.getArrayList();
                for (int j = 0; j < objectCount; j++) {
                    list.add(new Object());
                }
                pool.releaseArrayList(list);
            }
        }
    };
    t.start();
}

Après exécution de ce code en tant que benchmark, voici les résultats :

threadCount	listCount	objectCount	Temps avec pool (ms)	Temps sans pool (ms)
100	100	100	65	82
10	100000	100	1961	2051
100	100000	100	17484	24950

Le temps d'exécution est légèrement réduit. En contrepartie, après analyse de l'application de test grâce au Profiler de NetBeans, la consommation mémoire est d'environ 2 Mo supplémentaires pour 100 objets en attente dans le pool. Cette solution est donc intéressante à mettre en place pour des objets dont l'instanciation est très fréquente. Dans le cas où les instanciations se font plus rares, le gain en temps CPU est négligeable, et la consommation mémoire est plus étalée dans le temps.

GlassFish v3tp2

Vivien Barousse — Fri, 30 May 2008 18:06:10 +0100

Je sais que GlassFish v3tp2 est sorti depuis un petit bout de temps, mais je viens juste de le télécharger...

Ma première impression ?

Ça fait vraiment très bizarre :

viv@Eudoxe:~/Programs/glassfish-v3tp2$ time ./bin/asadmin start-domain
Command start-domain executed successfully.

real	0m0.976s
user	0m0.720s
sys	0m0.056s
viv@Eudoxe:~/Programs/glassfish-v3tp2$ time ./bin/asadmin stop-domain
Command stop-domain executed successfully.

real	0m0.553s
user	0m0.640s
sys	0m0.056s

Temps de démarrage de moins de une seconde, temps d'arrêt d'environ une demi seconde...

Sinon, les premières choses qui changent :

L'URL de l'interface d'administration. Ça paraît bête, mais j'ai mit bien 5 minutes à trouver la nouvelle (http://localhost:8080/admin)
Un déploiement d'applications bien plus rapide qu'avant
Le changement de fournisseur de persistance. GlassFish est passé de Toplink à EclipseLink, donc quelques petites modifications sont à faire dans les fichiers de configuration des applications spécifiques.

Le temps de tester un peu plus en profondeur et je pourrais donner un avis un peu plus complet, mais pour l'instant, je suis plutôt enthousiaste :)

Utiliser un certificat SSL avec GlassFish

Vivien Barousse — Wed, 28 May 2008 19:11:16 +0100

Après de nombreuses tentatives, c'est enfin fait ! Le certificat SSL de *.aperigeek.com est valide.

Voici les différentes étapes de mon aventure :
Pour information, mon serveur GlassFish utilise JKS en tant que KeyStore. Il s'agit du KeyStore par défaut sur une installation basique de GlassFish.

Générer une paire de clés

Le JDK embarque un outil permettant de gérer les KeyStore de type JKS. Cet outil porte le doux nom de keytool.

La première étape est donc de générer une paire de clés. Ces clés seront utilisées pour chiffrer les données entre le client et le serveur.

Pour générer une paire de clés, la commande magique est :

$ keytool -genkeypair -keyalg <algorithm> -keystore <keystore> -validity <validity> -alias <alias>

Petite note : Pour les utilisateurs du JDK 5, l'option -genkeypair est à remplacer par -genkey.

Les options à fournir :

<algorithm> corresponds à l'algorithme utilisé pour générer les clés (RSA, par exemple).
<keystore> corresponds au fichier contenant les clés du serveur. Par défault, ce fichier s'appelle keystore.pks et est stocké dans domains/domain/config.
<validity> corresponds au temps de validité du certificat, en jour (365 pour un an, par exemple).
<alias> corresponds au nom que vous souhaitez donner au certificat. Ce nom sera réutilisé par la suite pour désigner ce certificat à l'intérieur du serveur d'application.

keytool vous posera plusieurs questions, notamment :

Le mot de passe du KeyStore (par défaut, le mot de passe du KeyStore est changeit).
Un CN (Common Name). Mettez le nom de domaine pour lequel vous souhaitez créer un certificat (il est possible d'utiliser un wildcard, comme par exemple *.aperigeek.com pour tous les sous domaines aperigeek.com).
Les autres informations n'influent pas sur le certificat en lui même.

Générer une demande de certificat (CSR : Certificate Signing Request)

Ce fichier CSR va permettre d'effectuer une demande de certificat auprès d'une autorité de certification. Ce certificat permettra de justifier de l'identité du serveur auprès du client (afin d'éviter certaines attaques de type Man in the Middle, par exemple).

keytool permet de générer cette demande de certificat. La commande est :

keytool -certreq -alias <alias> -file <file> -keystore <keystore>

Avec les options :

<alias> corresponds au nom de votre certificat, celui que vous avez choisi dans la première étape.
<file> corresponds au fichier qui contiendra votre demande de certificat.
<keystore> à votre KeyStore, le même que dans la première étape.

Grâce à cette demande de certificat, nous allons pouvoir maintenant demander un certificat à une autorité de certification.

Demander un certificat à une CA

Libre à vous de choisir une autorité de certification (CA). J'ai choisi CAcert.org, car il s'agit d'une des rares autorité de certifications fournissant des certificats gratuitement.

La demande du certificat dépend ensuite de l'autorité que vous avez choisi. Il se peut que l'autorité de certification vous demande de la rajouter dans en tant que telle dans votre navigateur. Une fois votre certificat créé, vous allez pouvoir le récupérer sois sous la forme d'un fichier .cert, sois sous sa forme textuelle. Dans le deuxième cas, nous allons devoir copier le texte du certificat (y compris les balises -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----).

Insérer le certificat dans le KeyStore du serveur

Cette étape est assez complexe à réaliser avec keytool, j'ai donc pour ma part utilisé ce code Java :

public class InsertCert {
    public static void main(String[] args) {
        try {
            String certFile = "aperigeek.cert";
            String certName = "*.aperigeek.com";
            String keyStoreFile = "keystore.pks";
            String keyStorePassword = "changeit";
            
            CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
            Certificate cert = certFactory.generateCertificate(new FileInputStream(certFile));
            KeyStore keyStore = KeyStore.getInstance("JKS");
            keyStore.load(new FileInputStream(keyStoreFile), keyStorePassword.toCharArray());
            Key key = keyStore.getKey(certName, keyStorePassword.toCharArray());
            keyStore.setKeyEntry(certName, key, keyStorePassword.toCharArray(), new Certificate[]{cert});
            keyStore.store(new FileOutputStream(keyStoreFile), keyStorePassword.toCharArray());
        } catch (Exception ex) {
            Logger.getLogger(InsertCert.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

(inspiré de Using SSL with GlassFish v2 : Enterprise Tech Tips)

Les variables à remplacer :

certFile : le nom du fichier contenant le certificat, fourni par l'autorité de certification.
certName : le nom du certificat, que vous lui avez donné à l'étape 1
keyStoreFile : le nom du KeyStore
keyStorePassword : le mot de passe du KeyStore

Après exécution de ce morceau de code, voilà votre nouveau certificat entré dans la base de certificats de votre serveur d'applications. Il ne reste plus qu'à configurer GlassFish pour utiliser ce nouveau certificat !

Configuration du service HTTP

Dans la console d'administration de GlassFish :

Dans l'arbre : Configuration, Service HTTP, Listeners HTTP, nom-du-listeneur
Onglet SSL :
- Certificate Nickname : nom du certificat (que vous lui avez donné à l'étape 1)
- Cocher SSL3 et TLS
Onglet HTTP Listener :
- Cocher Security Enabled
Redémarrer GlassFish

Et voilà le résultat. Vous pouvez maintenant consulter mon blog en HTTPS avec un certificat valide, si le cœur vous en dit.

Exécuter du JavaScript en Java

Vivien Barousse — Sun, 25 May 2008 17:56:20 +0100

Suite à un sujet sur le forum comp.lang.java.programmer, j'ai fait quelque recherches sur l'exécution de scripts (en particulier JavaScript) dans un environnement Java SE.

L'exécution de scripts dans un environnement Java est fourni par le package javax.script (depuis Java 6). Un moteur de script est défini par l'interface ScriptEngine, dont l'implémentation nous est fournie par la classe ScriptEngineManager. Voici donc à quoi ressemble l'exécution de code JavaScript dans un environnement Java.

1. Exécution simple de script

Dans un premier temps, cet exemple montre comment exécuter un script simple. Le but est d'exécuter le code JS suivant :

function myFunction() {
    return (4 + 5);
}
myFunction();

Le but de ce code est de déclarer une méthode qui renvoie le résultat de 4 + 5, puis d'appeler cette méthode.

Voici maintenant l'exécution du même code en Java, en affichant le résultat sur la sortie standard :

public static void main(String[] args) {
    try {
        ScriptEngineManager mgr = new ScriptEngineManager();
        ScriptEngine engine = mgr.getEngineByName("JavaScript");
        String myJSCode = new StringBuffer()
                .append("function myFunction() {")
                .append("return (4 + 5);")
                .append("}")
                .append("myFunction();").toString();
        System.out.println(engine.eval(myJSCode));
    } catch (ScriptException ex) {
        ex.printStackTrace();
    }
}

Il est également possible de séparer la déclaration de la méthode de l'appel, ce qui permet plus de modularité (par exemple, nous déclarons une méthode une seule fois pour l'appeler plusieurs fois) :

public static void main(String[] args) {
    try {
        ScriptEngineManager mgr = new ScriptEngineManager();
        ScriptEngine engine = mgr.getEngineByName("JavaScript");
        String myJSCode = new StringBuffer()
                .append("var i = 12;")
                .append("function myFunction() {")
                .append("return (i++);")
                .append("}").toString();
        engine.eval(myJSCode);
        System.out.println(engine.eval("myFunction();"));
        System.out.println(engine.eval("myFunction();"));
        System.out.println(engine.eval("myFunction();"));
    } catch (ScriptException ex) {
        ex.printStackTrace();
    }
}

L'exécution de script est donc très simple.

2. Partage de variables

En plus d'être simple, l'exécution de scripts est également très puissante. Il est possible de partager des références vers des objets entre notre code Java et notre code JavaScript.

Un petit exemple simple, mettant en scène un StringBuffer dans lequel nous allons rajouter des données en JavaScript :

public static void main(String[] args) {
    try {
        ScriptEngineManager mgr = new ScriptEngineManager();
        ScriptEngine engine = mgr.getEngineByName("JavaScript");
        StringBuffer s = new StringBuffer();
        engine.put("s", s);
        engine.eval("s.append('toto');");
        System.out.println(s.toString());
    } catch (ScriptException ex) {
        ex.printStackTrace();
    }
}

Il est donc possible de modifier des objets Java directement à l'intérieur de notre moteur de script.

Enfin, un dernier point concerne les objets immuables (comme la classe String, par exemple). En effet, une instance de String ne peut pas changer de contenu. Un nouvel objet doit être créé. Dans ce cas, il est possible de récupérer un objet créé dans notre script :

public static void main(String[] args) {
    try {
        ScriptEngineManager mgr = new ScriptEngineManager();
        ScriptEngine engine = mgr.getEngineByName("JavaScript");
        String str = "toto";
        engine.put("str", str);
        engine.eval("str = str.concat(' tata');");
        str = (String) engine.get("str");
        System.out.println(str);
    } catch (ScriptException ex) {
        ex.printStackTrace();
    }
}

L'exécution de scripts est donc assez aisée dans un environnement Java 6. L'API permettant cette exécution est à la fois simple et puissante, puisqu'elle permet même la modification d'objets Java.

Seul bémol, sur ma machine (JVM 1.6.0_06-b02, sous Linux), il semblerais que le moteur de JavaScript soit le seul disponible...

Nouveau thème pour mon blog

Vivien Barousse — Sat, 24 May 2008 14:15:01 +0100

Et oui Keitboor, Matt t'a dénoncé ! Il m'a avoué ce que tu pensais de mon ancien thème. Et je te l'accorde, il n'était pas très esthétique.

Mais maintenant, ce n'est plus le cas !

J'ai décidé d'abandonner Basic, le thème par défaut de Roller, et d'en utiliser un plus frais, unqualified, un des nombreux thèmes proposés par freeCSStemplates.org.

En espérant qu'il vous plaise à vous aussi (vous, mes quelques lecteurs).

Astuce Java #5 : for-each sur une map

Vivien Barousse — Tue, 20 May 2008 01:32:47 +0100

Petite astuce pour iterer sur une Map dans une boucle for-each, en attendant Java 7.

Il s'agit de considérer une Map comme une collection de Map.Entry :

Map<Integer, String> myMap = new HashMap<Integer, String>();
// ...
for (Map.Entry entry : myMap.entrySet()) {
    System.out.println(entry.getKey() + "=" + entry.getValue());
}

Via A better way to iterate java maps.

Premiers pas avec Lucene : Recherche dans l'index

Vivien Barousse — Mon, 19 May 2008 20:26:35 +0100

Dans la continuité de l'entrée précédente, qui parlait de l'indexation de données avec Lucene, je vais aujourd'hui parler des Query, les objets permettant de faire des requêtes de recherche dans l'index.

Prenons un petit exemple ; dans l'index que nous avons créé hier, essayons de rechercher les documents dont le content contient le mot-clé "Java".

Les différentes étapes à suivre dont les suivantes :

Créer un IndexReader, un objet capable de lire l'index.
Créer un objet de type IndexSearcher, un objet capable de faire une recherche dans un index, à travers un IndexReader.
Créer un objet de type QueryParser. Cet objet va parser la requête passée, et l'interpréter afin de fournir les résultats les plus pertinents.
Parser la requête, nous obtiendrons un objet de type Query, contenant la requête à exécuter.
Exécuter la requête, qui nous renvera une liste de résultats (sous la forme d'un objet de type Hits, contenant les résultats.
Itérer sur cette liste, afin d'afficher les résultats de notre recherche.

Un petit exemple de code pour concrétiser tout ça :

IndexReader index = IndexReader.open(INDEX_ROOT);
Searcher searcher = new IndexSearcher(index);
QueryParser parser = new QueryParser("content", new StandardAnalyzer());
Query results = parser.parse("Java");
Hits hits = searcher.search(results);
Iterator<Hit> iterator = hits.iterator();
while (iterator.hasNext()) {
    Hit hit = iterator.next();
    System.out.println(hit.get("title") + ", by " + hit.get("author"));
}

Les résultats sont automatiquement triés par pertinence. Il est possible de récupérer un "score" représentatif de la pertinence d'un résultat grâce à la méthode Hit.getScore().

Voici donc un premier et rapide aperçu du mécanisme de requêtes dans des index Lucene. Le système de requête en entier est bien plus complexe, et permet des requêtes beaucoup plus poussées. Je continuerais donc cette série d'articles au fur et à mesure de mes découvertes. En attendant, la documentation officielle de Lucene est très complète.

viv's blog

Charger partiellement une entité avec JPA

Première solution : FetchType.LAZY

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

Aperiquiz #4 : Integer equals Integer

Explication :

Types primitifs : pièges courants

27/10 != 2.7

return (int) 2.7 - 2.4;

Aperiquiz #3 : Paramètres de méthodes

Explication :

NetBeans tip : replier un bloc de code

Aperiquiz #2 : Exception générique

Explication :

Aperiquiz #1 : Finally returns

Comment se débarasser de com.sun.messaging.jmq.io.Packet cannot be cast to com.sun.messaging.jms.ra.DirectPacket ?

RichFaces : Filtrer et trier une DataTable

Mise en place d'une Rich DataTable

Rajout des fonctionnalités de tri

Filtrer les données

RichFaces

NetBeans 6.5 est parmis nous

EJB 3.1, on y arrive !

Les singletons

Une meilleure gestion des timers

Les noms JNDI globaux

Les Session Beans "sans interface"

Java/C : Sockets

Java/.NET : Opérateurs

Surcharge des opérateurs

Indexeurs

Neal Gafter quitte Google... Pour Microsoft

Java/.NET : Types de données

Fichiers sources

Types primitifs - types valeurs

Types références

Structures

Enumérations

Espaces de nommages

Types génériques

Java/.NET : Concepts élémentaires

Compilation

Environnement d'exécution

Bibliothèques de base

Java/.NET : Introduction

Rédaction estivale

NetBeans 6.5 en approche

Changement de serveur

Astuce Java #6 : Enum et toString

Système d'inclusion en JSF

index.jsp

content.jsp

Points importants

Optimisation : Utilisation d'un pool d'objets

GlassFish v3tp2

Utiliser un certificat SSL avec GlassFish

Générer une paire de clés

Générer une demande de certificat (CSR : Certificate Signing Request)

Demander un certificat à une CA

Insérer le certificat dans le KeyStore du serveur

Configuration du service HTTP

Exécuter du JavaScript en Java

1. Exécution simple de script

2. Partage de variables

Nouveau thème pour mon blog

Astuce Java #5 : for-each sur une map

Premiers pas avec Lucene : Recherche dans l'index

Première solution : `FetchType.LAZY`

`return (int) 2.7 - 2.4;`

`index.jsp`

`content.jsp`