Discussion :

[gchauvet]

Bonjour à tous,

Je rencontre un problème avec des constantes finales après la compilation des sources en une seule étape :
Soit les deux classes A et B définies comme suit :

Fichier A.java :

Code :

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

1
2
3
4
public class A
{
    static final String S = "avant";
}

Fichier B.java :

Code :

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

1
2
3
4
5
6
7
public class B
{
    public static void main(String args[])
    {
        System.out.println(A.S);
    }
}

On compile tout ça et on exécute B :
javac A.java B.java
java B
Le résultat affiché sur la console est :

avant

On modifie A.java comme suit :
Fichier A.java :

Code :

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

1
2
3
4
public class A
{
    static final String S = "après";
}

On compile A.java qui est le seul modifié et on exécute B :
javac A.java
java B
Le résultat affiché sur la console est toujours :

avant

Alors qu’on pouvait s’attendre à obtenir

après

C'est franchement curieux...

Merci par avance !

[1] Testé avec les JDK Oracle 6/7/8

[adiGuba]

Salut,



C'est normal puisqu'il s'agit de constante, c'est à dire une variable "final" initialisée en ligne avec une expression littérale (grosso-modo une chaine ou une valeur numérique).
A la compilation la variable est directement remplacé par sa valeur.
Le compilateur pouvant même effectuer certaines opérations dès la compilation (comme des concaténations ou des opérations mathématiques).

Lorsqu'on modifie une constante il faut impérativement recompiler tout les fichiers qui l'utilisent pour que ce soit prix en compte.


Si tu veux éviter ce comportement, il faut éviter d'utiliser une constante.
Pour cela il faut que l'initialisation ne se limite pas à une expression littérale.
Exemple :

Code :

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

1
2
3
4
5
    static final String S = new String("avant");
// ou bien :
    static final String S = String.valueOf("avant");
// ou bien :
    static final String S = "avant".toString();

a++

PS : bien sûr il faut recompiler le tout au moins une fois pour que la modification se propage.

[gchauvet]

Salut,


Merci, du coup je suis partie sur cette solution :

Code :

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

static final String S = null!=null ? null : "avant";

[thelvin]

Si vous ne voulez pas que le prochain collègue qui passe par là efface ce qui ne peut être que des inepties à leurs yeux, vous pouvez faire quelque chose comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
static final String S = nonConstant("avant");
 
/**
 * Returns the given String, ensuring the compiler won't take it as a constant.
 *
 * Sometimes you don't want your variables to be compiled as constants but they will anyway if they respect the convention for it.
 * The result of a method call is never a constant, so just call this method when you want your String to not be compiled as a constant.
 */
private static String nonConstant(String string) {
  return string;
}

[hwoarang]

Merci, du coup je suis partie sur cette solution :

Code :

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

static final String S = null!=null ? null : "avant";

Juste pour enfoncer le clou, c'est une très mauvaise solution. Si ce projet passe par les mains de quelqu'un d'autre, il changera ca au premier coup d'oeil. Et meme toi, lorsque le temps aura passé et que tu ne te rappelleras plus pourquoi tu as fait ca, tu le changeras et te disant que tu as fait un copié/collé raté. D'autre part, un compilateur un peu avancé peut très bien optimiser ce genre de chose (en fait, je suis meme étonné que cela marche puisque la condition est toujours vraie, je me serais attendu à ce que cela soit optimisé).
A mon avis, le minimum est

Code :

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

static final String S = new String("avant");

qui montre clairement que le new n'est pas un hasard (et un petit commentaire peut etre utile aussi). Sinon, la méthode de thelvin permet aussi de rendre evident que ce code n'est pas juste un vilain copié/collé.

[gchauvet]

Bonjour à tous,

Le code en question est injecté dans les sources avant la compilation par un système d'expression régulière via Ant (j'y peux rien, c'est comme ça depuis bientôt plus de 15 ans )
Du coup, j'ai tout de même revu l'écriture en passant par le new String("");

Quoi qu'il en soit, je trouve cette optimisation du compilateur "déplacé"; elle aurait dû être faite par le JIT...

Merci à tous

[thelvin]

Quoi qu'il en soit, je trouve cette optimisation du compilateur "déplacé"; elle aurait dû être faite par le JIT...

N'importe quoi -_-°. Le JIT ne va pas s'amuser à passer sur le chargement d'une classe, et un littéral String n'a aucune raison d'être transformé en instance plus d'une fois par la classe dans laquelle il figure, donc forcément ça arrivera au plus tard au chargement de la classe... Pas la moindre chance donc de pouvoir concerner le JIT d'une quelconque manière.

Dis juste que toi tu aurais préféré que les constantes, ça ne marche pas d'une classe à l'autre, seulement dans la classe en cours, parce qu'en marchant d'une classe à l'autre ça veut dire que les constantes d'une classe accédées par une autre classe, ne nécessitent pas de charger cette classe pour vérifier que la constante n'a pas changé depuis la dernière compilation, et ça ne t'arrange pas.