Blog de Vincent Brabant : NetBeans, Java et autres

Un article de vbrabant    6 Commentaires

Pour vous préparer à la Certification Java SCJP 5.0, nous vous proposons quelques fiches.

Aujourd’hui, en voici une concernant l’autoboxing/unboxing

L’AutoBoxing/UnBoxing

La fonctionnalité d’autoboxing / unboxing est une fonctionnalité qui fut très attendue par certains programmeurs. Mais l’introduction de cette fonctionnalité peut également vous jouer de mauvais tours si vous n’y prenez garde.

AutoBoxing
L’autoboxing est l’opération qui consiste à envelopper automatiquement une primitive dans sa classe enveloppe correspondante.

Au lieu d’être obligé d’écrire du code semblable à ceci:

Integer i = new Integer(1000);
Boolean b = new Boolean(true);
Character c = new Character('A');

vous pouvez maintenant écrire le code suivant:

Integer i = 1000;
Boolean b = true;
Character c = 'A';

Ce qui est, vous le reconnaitrer, tout de même plus pratique, pour encoder.

Mais attention: l’autoboxing introduit une petite subtilité.
Il faut bien comprendre quelle est le code qui est généré par l’autoboxing.

Lorsque vous écrivez le code source suivant

Integer i = 100;
Boolean b = true;
Character c = 'A';

Le bytecode généré ne correspond pas du tout au bytecode généré pour le code source suivant:

Integer i = new Integer(100);
Boolean b = new Boolean(true);
Character c = new Character('A');

Il correspond plutôt au bytecode généré pour le code source suivant:

Integer i = Integer.valueOf(100);
Boolean b = Boolean.valueOf(true);
Character c = Character.valueOf('A');

Et vous devez vraiment penser au fait que le compilateur travaille comme cela. Car cela peut avoir un énorme impact sur votre code.

Imaginer le code suivant:

public class ComparerDesBooleens {
    public static void main(String[] args) {
 
        //Bloc 1: Comparer des Boolean en utilisant les constructeurs
        {
            Boolean b = new Boolean(true);
            Boolean b2 = new Boolean(true);
            if (b==b2) {
                System.out.println("b == b2");
            }
            else {
                System.out.println("b <> b2");
            }
        }
        //Bloc 2: Comparer des Boolean en utilisant valueOf(boolean)
        {
            Boolean b = Boolean.valueOf(true);
            Boolean b2 = Boolean.valueOf(true);
             
            if (b==b2) {
                System.out.println("b == b2");
            }
            else {
                System.out.println("b <> b2");
            }
        }
 
        //Bloc 3: Comparer des Boolean en utilisant valueOf(String)
        {
            Boolean b = Boolean.valueOf("true");
            Boolean b2 = Boolean.valueOf("true");
             
            if (b==b2) {
                System.out.println("b == b2");
            }
            else {
                System.out.println("b <> b2");
            }
        }
         
        //Bloc 4: Comparer des Boolean en utilisant l'autoboxing
        {
            Boolean b = true;
            Boolean b2 = true;
             
            if (b==b2) {
                System.out.println("b == b2");
            }
            else {
                System.out.println("b <> b2");
            }
        }
    }
}

Le résultat à la console sera

b <> b2
b == b2
b == b2
b == b2

Pourquoi ?

Le fait d’appeler un constructeur, on crée toujours un nouvel Objet en mémoire. Et lorsqu’on compare les deux références, elles pointes vers deux objets bien distincts.

Par contre, les deux méthodes valueOf() ont été optimisées. En effet, la classe Boolean tient en cache deux objets: TRUE et FALSE. Et les méthodes valueOf() ont été optimisées pour toujours retourner une référence à l’un de ces deux objets.

Et l’autoboxing a été implémenté de telle façon qu’en réalité on appelle la méthode valueOf().

Nous venons de voir des exemples avec la classe Boolean qui possédait en effet une méthode valueOf(boolean). Mais les autres classes primitives, comme Integer ou Float, ne possedent pas de méthode valueOf(int) ou valueOf(float), me direz vous. En effet, cela était vrai jusqu’à présent. Mais depuis le JDK 5.0, ces classes possèdent ces méthodes. Et ce sont ces méthodes qui sont appelées lorsque vous utilisez l’autoboxing.

Si on reprend donc l’exemple précédent utilisé pour la classe Boolean et qu’on l’adapte pour la classe Integer. On aura le code suivant:

public class ComparerDesEntiers {
    public static void main(String[] args) {
         
        // On effectue 4 comparaisons avec des entiers construits 4 fois de manières différentes
 
        {
            Integer b = new Integer(1000);
            Integer b2 = new Integer(1000);
             
            if (b==b2) {
                System.out.println("b == b2");
            }
            else {
                System.out.println("b <> b2");
            }
        }
         
        {
            Integer b = Integer.valueOf(1000);
            Integer b2 = Integer.valueOf(1000);
             
            if (b==b2) {
                System.out.println("b == b2");
            }
            else {
                System.out.println("b <> b2");
            }
        }
         
        {
            Integer b = Integer.valueOf("1000");
            Integer b2 = Integer.valueOf("1000");
             
            if (b==b2) {
                System.out.println("b == b2");
            }
            else {
                System.out.println("b <> b2");
            }
        }
        {
            Integer b = 1000;
            Integer b2 = 1000;
             
            if (b==b2) {
                System.out.println("b == b2");
            }
            else {
                System.out.println("b <> b2");
            }
        }
    }
}

Qu’allons nous avoir à l’exécution ?
Le même résultat que pour la classe Boolean ?

b <> b2
b == b2
b == b2
b == b2

Non. Et la raison en est toute simple. C’est qu’on ne pouvait pas imaginer de mettre en cache un objet par nombre entier. Pour la classe Boolean, c’était facile, il n’y avait que 2 valeurs. Mais pour la classe Integer, il y a 2 exposants 32 valeurs possibles. Cela aurait fait 2 exposants 32 objets à mettre en cache. Cela n’était pas pensable. Et encore moins pour les Long, Float et/ou les Double.

Le résultat de l’exécution est donc:

b <> b2
b <> b2
b <> b2
b <> b2

Mais les développeurs de Sun ne se sont pas arrêtés là. Non, ils ont tout de même décider de mettre en cache, pour les classes enveloppes représentant des nombres entiers, les classes correspondantes aux nombre compris entre -128 et 127. Excepté pour la classe Character, qui ne peut contenir que des nombres entiers non signés, où la cache va de 0 à 127.

Si vous reprenez le code précédent concernant l’Integer, mais en utilisant la valeur 100 au lieu de 1000, le résultat de l’exécution sera donc:

b <> b2
b == b2
b <> b2
b == b2

Tiens. Pourquoi avons-nous b<>b2 comme résultat à la console pour

Integer b = Integer.valueOf("1000");
Integer b2 = Integer.valueOf("1000");
if (b==b2) {
  System.out.println("b == b2");
}
else {
  System.out.println("b <> b2");
}

Tout simplement, parce qu’il fallait qu’un programme écrit et compilé pour le JDK 1.4 donne les même résultats lorsqu’on qu’il est exécuté avec une JRE 1.4 qu’avec une JRE 5.0. Et la méthode valueOf(String value) existait déjà dans les versions précédentes du JDK 5.0 pour la classe Integer. Et retournait toujours un nouvel objet.