Discussion :

[vincent63]

Bonjour,
Dans une application, je me suis retrouvé confronté à une null pointer exception. Ce genre de problème est en général simple à résoudre. Là, la correction a été un peu plus subtile. Du coup je vous propose de la chercher. J'espère que ça vous amusera un peu

La règle : ne pas utiliser le debugger => trop facile
Eviter les corrections du genre si truc == null alors truc = new Machin();
La correction ne demande en fait qu'une très très légère modification.

Voilà une version simplifiée des classes qui vont vous permettre de reproduire le bug.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
package com.test.java;
 
public class Application {
 
    public static void main(String[] args) {
        new Fille().printMessage();
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
package com.test.java;
 
public class Fille extends Mere {
 
    private String message = null;
 
    public Fille() {
        super();
    }
 
    public void initialiseFille() {
        System.err.println("1. J'initialise l'object message");
        message = "Bonjour le monde";
        System.err.println("2. Sa valeur est : " + message);
    }
 
    public void printMessage() {
        System.err.println("3. J'affiche la taille du message");
        System.err.println("Taille du message = " + message.length());
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
package com.test.java;
 
public abstract class Mere {
 
    public Mere() {
        initialiseMere();
    }
 
    private void initialiseMere() {
        initialiseFille();
    }
 
    public abstract void initialiseFille();
}

[publicStaticVoidMain]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
package com.test.java;
 
public class Application {
 
    public static void main(String[] args) {
        new Fille().printMessage();
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
package com.test.java;
 
public class Fille extends Mere {
 
    private String message = null;
 
    public void initialiseFille() {
        System.err.println("1. J'initialise l'object message");
        message = "Bonjour le monde";
        System.err.println("2. Sa valeur est : " + message);
    }
 
    public void printMessage() {
        System.err.println("3. J'affiche la taille du message");
        System.err.println("Taille du message = " + message.length());
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
package com.test.java;
 
public abstract class Mere {
 
    public Mere() {
        initialiseMere();
    }
 
    private void initialiseMere() {
        initialiseFille();
    }
 
    public abstract void initialiseFille();
}

Le problème se trouve dans le main quand tu appelles la methode printMessage(). La
variable message n'est pas initialisée.

[vincent63]

Effectivement, la variable message est null.
On peut le voir aux traces lors de l'exécution.
Mais si tu regardes tes traces, tu peux aussi voir que juste avant de demander sa taille, on affiche sa valeur et elle n'est pas null.
On obtient quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
1. J'initialise l'object message
2. Sa valeur est : Bonjour le monde
3. J'affiche la taille du message
NullPointerException...

Il te reste donc à trouver la correction.
Bon courage.

[Alkhan]

bonjour,
la c'est un peu facile
il suffit que ta variable message soit declaré comme ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
private String message = "";

[eclesia]

trouvé.

le constructeur de la classe mère donne bien une valeur au message mais le constructeur de la classe fille la repasse a null.

il faut appeller le initialiseFille apres le super, ou mettre la variable message dans la classe mère ( en passant le private en protected).

[fallo]

il ne faut pas initialiser les valeures par defaut,car ca les réinitialises apres l'appel du constructeur parent. Donc faire une déclaration comme suis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

private String message;

en plus la fonction inialiserfille semble servir a initaliser les valeures de la fille... c'est contradictoire avec la déclaration.

[DevTeam_]

trouvé.

le constructeur de la classe mère donne bien une valeur au message mais le constructeur de la classe fille la repasse a null.

il faut appeller le initialiseFille apres le super, ou mettre la variable message dans la classe mère.

[vincent63]

Félicitations pour toutes ces réponses. Celle que j'attendai a été donné par fallo.
En effet, le petit truc subtil qui fait planter ce petit bout de code est le "=null" dans la déclaration.
En l'enlevant, tout fonctionne sans avoir à déplacer ni méthode ni attribut de classe.
Pour fallo

[adiGuba]

Salut,


Je ne suis pas tout à fait d'accord sur la réponse : cela résoud bien le "bug" mais ce n'est pas très propre !!!


En fait ce n'est pas un bug en soit puisque c'est un effet de l'ordre de création des objets, qui suit le déroulement suivant :

1. Allocation de l'espace mémoire pour l'objet. Tous les attributs sont initialisés à leur valeur par défaut (null pour les références, 0/0.0/false pour les types primitifs).
2. Les constructeurs sont appellés de manière récursive jusqu'au constructeur de base. Les constructeur s'exécute donc en ordre inverse (du plus haut au plus bas de la hierarchie), sachant que chaque constructeur s'effectue en deux étapes :
   
   • Exécution d'un méthode <init> qui exécutes le "code d'instance" (initialisation des attributs et bloc {} de la classe).
   • Exécution du code du constructeur.

Pour plus de détail jetez un oeil aux specs : http://java.sun.com/docs/books/jls/t...tion.html#12.5

Ce qui donne dans ton cas :

• Allocation de la mémoire pour un objet Fille
• Initialisation et exécution du constructeur de Object (qui ne fait rien).
• Initialisation de Mere (ce qui ne fait rien), et exécution du constructeur (qui appelle initialiseMere() puis initialiseFille()).
• Initialisation de Fille (qui exécute message = null;) et exécution du constructeur (qui ne fait rien).

Du coup message se retrouve à nouveau à null...





Là où je ne suis pas d'accord sur la solution, c'est que le problème vient plutôt du fait que le constructeur de la classe Mere appelle (indirectement) une de ses méthodes virtuelles (initialiseFille() en l'occurence)...

Cela devrait être interdit car cela peut générer un grand nombre de problème de ce genre, et cela implique que les classes filles respectent un certains nombres de conditions liés à l'implémentation de la classe parente...


a++

[vincent63]

Là où je ne suis pas d'accord sur la solution, c'est que le problème vient plutôt du fait que le constructeur de la classe Mere appelle (indirectement) une de ses méthodes virtuelles (initialiseFille() en l'occurence)...

Je suis assez d'accord avec toi. En fait, il me semble que cela fait parti des préconisations que l'on peut trouver dans le livre Java efficace, à savoir qu'un constructeur ne devrait appeller que des méthodes 'private final'. Cela évite les problèmes de ce genre.

Ceci dit, je trouvai amusant de voir qu'en utilisant ce type d'architecture (ie une sorte de patron de méthode sur un constructeur), on pouvait rencontrer ce genre d'erreur peut-être pas évidente à corriger.

Car après tout, cette façon d'initialiser un objet pourrait tout à fait être sensée.

Dans le cas qui m'intéresse, il s'agissait d'initialiser un composant graphique. La partie supérieure est identique à tous les objets filles. La spécialisation se fait justement dans la partie inférieur du composant. D'où l'initialisationFille qui permettait aux filles de créer leur propre partie.

Il y a surement de meilleurs façons de faire, mais dans la hâte c'est celle là que j'avais choisi.

Cela m'a, en tout cas, permis de voir la différence entre la déclaration simple d'un object et sa déclaration + initialisation à null qui de toute évidence ne sont pas traités de la même manière.

La solution proposée permettait juste de mettre en évidence cette différence.

En tout cas, je te remercie pour tes précisions et pour le lien qui me semble assez intéressant.

[adiGuba]

Je suis assez d'accord avec toi. En fait, il me semble que cela fait parti des préconisations que l'on peut trouver dans le livre Java efficace, à savoir qu'un constructeur ne devrait appeller que des méthodes 'private final'. Cela évite les problèmes de ce genre.

private ou final. Du moment que la méthode est private ou final elle ne peut pas être redéfini dans une éventuelle classe fille, ce qui évite ce genre de problème

Car après tout, cette façon d'initialiser un objet pourrait tout à fait être sensée.

L'initialisation, c'est le rôle du constructeur. Chaque constructeur doit initialiser les éléments de son propre type sans avoir à se soucier des éventuels types enfants...

De plus cela simplifie le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public abstract class Mere {
 
    public Mere() {
        // initialisation ici
    }
 
}
 
 
public class Fille extends Mere {
 
    private String message = null;
 
    public Fille() {
        System.err.println("1. J'initialise l'object message");
        message = "Bonjour le monde";
        System.err.println("2. Sa valeur est : " + message);
    }
 
    public void printMessage() {
        System.err.println("3. J'affiche la taille du message");
        System.err.println("Taille du message = " + message.length());
    }
}

Et c'est plus propre car il n'y a pas de méthode initialiseFille() en public (qui pourrait donc être rappelé par la suite )

a++

[vincent63]

private ou final tu as raison , on va dire que j'ai oublié le ou

L'exemple que j'ai donné était une version simplifiée. L'objectif était juste de montrer cette subtilité dans la déclaration, pas de montrer un cas concret ou réel d'utilisation de ce genre d'archi.

L'idée, dans mon appli, était en gros d'initialiser dans la mère un composant principale, mettons un JPanel, avec deux parties.

La première qui contient une partie commune à tous les objects qui héritent de la classe mère.

La seconde qui est spécifique à chaque fille.

L'idée était donc à l'initialisation de la mère d'ajouter le composant spécifique sous le composant commun défini dans la classe mère, d'où l'utilisation d'une méthode abstraite qui devait renvoyer le composant spécifique. C'est vraiment l'idée du patron de méthode réutilisé dans la construction d'un object.

Bon, sûr que dit comme ça, ça ne doit pas être très clair. Mais il ne faut pas s'arrêter sur l'exemple qui est vraiment une version simplifié. Parce que là évidement, cela n'a aucun intéret, je te l'accorde.

L'initialisation, c'est le rôle du constructeur. Chaque constructeur doit initialiser les éléments de son propre type sans avoir à se soucier des éventuels types enfants...

Là dessus je ne suis pas tout à fait d'accord. Il n'est pas impensable de demander aux classes filles des "précisions" sur leur spécialisation qui permettraient de modifier certains comportements. C'est exactement ce qui se fait sur un patron de méthode. Une méthode principale qui délègue aux filles une partie du travail pour exploiter leurs particularités. C'est tout à fait envisageable dans une construction.