Discussion :

[Stessy]

Bonjour,

pourquoi doit-on qualifier les variables statiques dans des blocs statiques lorsque le bloc est déclaré avant la variable ??

Exemple qui fonctionne:

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class TestClass {
 
    static {
        System.out.println(TestClass.A);
        A = 20;
    }
 
    public static final int A;
 
    static {
        System.out.println(A);
    }
}

Exemple qui ne fonctionne pas:

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class TestClass {
 
    static {
        System.out.println(A);
        A = 20;
    }
 
    public static final int A;
 
    static {
        System.out.println(A);
    }
}

Merci d'avance pour vos réponses.

[thelvin]

Hello,

C'est pas une question de static, c'est une question de final. Une variable (locale ou membre) finale doit être assignée exactement une fois, et cela doit arriver avant qu'on en lise la valeur.

L'équivalent non-static est :

- ne marche pas :

Code :

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

1
2
3
4
5
6
7
8
9
10
public class TestClass {
 
  public TestClass() {
    System.out.println(a);
    a = 20;
    System.out.println(a);
  }
 
  public final int a;
}

- marche :

Code :

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

1
2
3
4
5
6
7
8
9
10
public class TestClass {
 
  public TestClass() {
    System.out.println(TestClass.this.a);
    a = 20;
    System.out.println(a);
  }
 
  public final int a;
}

En fait la question qui se pose, c'est pourquoi ton premier exemple marche. (Enfin, compile. On ne peut pas vraiment dire qu'il marche puisqu'il affiche deux valeurs différentes pour une même variable finale.)
Je ne savais pas qu'il marcherait. Je pensais effectivement qu'un accès qualifié ou non qualifié serait équivalent pour le compilateur.

Mais ce n'est pas le cas, parce que dans le cas général, l'accès qualifié pourrait accéder à une variable d'une autre classe, et dans ce cas la contrainte sur final ne serait pas vérifiable : on ne sait pas si elle a bien été initialisée dans cette classe, ou non.
Java a décidé que l'accès qualifié serait traité de la même manière, que ce soit pour désigner la classe en cours ou n'importe quelle classe.
Donc, contrairement à ce que j'aurais pensé de prime abord, l'accès qualifié à une variable de la classe en cours, n'est pas 100% équivalent à l'accès direct à cette variable.

[Stessy]

Merci pour ton retour.

Je parlais du static justement parce que qu'il y ait ou non le mot clé final, le résultat sera le même. C'est à dire obligation de qualifier la variable static avant de déclarer celle-ci.

Compile:

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class TestClass {
 
    static {
        System.out.println(TestClass.A);
        A = 20;
    }
 
    public static int A;
 
    static {
        System.out.println(A);
    }
}

Ne compile pas:

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class TestClass {
 
    static {
        System.out.println(A);
        A = 20;
    }
 
    public static int A;
 
    static {
        System.out.println(A);
    }
}

[thelvin]

Ah, pardon, je n'avais pas remarqué non plus. Ceci dit, la même chose s'observe à nouveau sans les static. Dans un bloc d'initialisation, statique ou d'instance, on ne peut pas accéder à la valeur d'une variable avant que cette variable ait été déclarée.

Mais concrètement ce n'est pas qu'il faut qualifier le nom si la variable est déclarée après. C'est qu'il faut déclarer la variable avant, point barre.

Ça compile quand même en qualifiant le nom de la variable, pour raisons similaires à au-dessus : en accédant à une variable de classe, il n'y a pas de question de déclarée avant ou après. Et pour homogénéité ça s'applique même si la classe qualifiée est la classe en cours.
Mais on ne peut pas dire que ça marche, car ça ne respecte pas une règle "évidente" : si la variable est déclarée avec une assignation de valeur, y accéder de cette manière avant la déclaration, ne verra pas la valeur assignée. Pour le dire autrement, ça ne sert à rien, puisque la variable n'a pas encore la valeur qu'il serait utile de consulter.


Maintenant, pourquoi est-ce qu'une variable ne doit pas être lue dans un bloc d'initialisation avant d'être déclarée, alors ça... Java l'a décidé.

Ça paraît logique : une déclaration de variable peut potentiellement inclure une première assignation de cette variable. Donc véritablement "faire" quelque chose : évaluer une expression et assigner son résultat à la variable.
Et les blocs d'initialisations s'exécutent dans l'ordre où ils apparaissent dans la classe. Donc logiquement les déclarations de variables, en dehors de ces blocs, devraient aussi s'exécuter dans l'ordre de leur apparition, entre les deux blocs où elle se situe. Et en cela, c'est peu pertinent d'utiliser la variable avant que sa valeur de départ ne lui ait été assignée.
En généralisant cette règle, elle s'applique aussi si la déclaration de variable ne contient pas d'assignation et n'exécute donc rien du tout.

[Stessy]

Maintenant si tu lances ce bout de code, tu remarqueras qu'il affichera 0 dans le premier bloc statique.

Mais je suis d'accord sur l'absurdité d'utiliser une variable avant que celle-ci ait été déclarée, statique ou pas.

Je révisais mes gammes pour le OCA et OCP et je suis tombé sur ce cas assez bizarre en faisant des tests.

Et j'ai beau retourner dans tous les sens la spec java, il n'y est fait mention nulle part.

[thelvin]

Maintenant si tu lances ce bout de code, tu remarqueras qu'il affichera 0 dans le premier bloc statique.

Oui, mais il affichera 0 quelle que soit la valeur donnée à A lors de sa déclaration.

Et j'ai beau retourner dans tous les sens la spec java, il n'y est fait mention nulle part.

8.3.2.3: Restrictions on the use of Fields during Initialization

Bien sûr, la raison pour laquelle l'usage est accepté avec un nom qualifié, est pure spéculation de ma part. Mais elle me semble logique.