Discussion :

[Orni-Dev]

Bonjour, je viens de remarquer quelquechose que je trouve surprenant avec le compilateur java d'oracle.

Je m'explique :
Soit A une classe statique qui définie une constante CONST_1 dans un jar JAR1. [module 1 maven]

Code :

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

public final String CONST_1 = "MASTRONG"

]

Soit B une classe qui se sert de la constante CONST_1 dans un JAR2. [module 2 maven]

Code :

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

private final String MA_LOCAL_CONST = CONST_1 + "-LOCAL"

]

Aujourd'hui je dois faire une modification car CONST_1 est mal écrite.


Je change la valeur de CONST_1 dans JAR1.

Code :

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

public final String CONST_1 = "MASTRING"

]
et je re-déploie JAR1 sans toucher au reste (ça me semblait logique).
La modification n'est pas prise en compte par mon JAR2 (bizarre).

J'ai donc été décompilé ma class B de mon JAR2 pour comprendre.

et voici le résultat :

Code :

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

1
2
3
4
5
6
7
8
9
Le code compilé [puis décompilé] pour la classe B me donne ceci pour ma string MA_LOCAL_CONST

	

	
Code  :
	
Sélectionner tout -
	Visualiser dans une fenêtre à part
	
MA_LOCAL_CONST = (new StringBuilder()).append("MASTRONG").append("-LOCAL").toString();

Le comportement me parait logique quand on a les 2 classes dans le même jar [module maven]. Mais quand on en a plusieurs, je trouve cela plus que surprenant. Si je dois toujours tout recompiler à chaque fois que je modifie un truc ça devient l'enfer [et l'interet de sortir les constantes ?]. Quelqu'un pourrait-il m'expliquer la raison de cette "optimisation" ?

D'où voici ma question, y'aurait-il une possibilité pour que le compilateur garde la constante et ne copie pas la valeur ?

Merci

[thelvin]

Le comportement me parait logique quand on a les 2 classes dans le même jar [module maven]. Mais quand on en a plusieurs, je trouve cela plus que surprenant.

Le compilateur ne va pas s'amuser à avoir des règles différentes suivant les .jar. On devrait se douter qu'on a soit toujours l'un, soit toujours l'autre.

Si je dois toujours tout recompiler à chaque fois que je modifie un truc ça devient l'enfer [et l'interet de sortir les constantes ?].

Plutôt d'accord, mais c'est ainsi.
Pour information, il n'y a jamais eu d'intérêt à sortir les constantes. Les constantes doivent être là où elles doivent être.

Quelqu'un pourrait-il m'expliquer la raison de cette "optimisation" ?

Ne pas avoir besoin de faire appel à des classes externes pour utiliser des constantes. Comme avec un seul .jar.

D'où voici ma question, y'aurait-il une possibilité pour que le compilateur garde la constante et ne copie pas la valeur ?

Avec des constantes, non. En gardant une variable finale, oui :

Code :

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

1
2
3
4
public static String nonConstant(String s) {
  return s;
}
public final String CONST_1 = nonConstant("MASTRONG");

[Orni-Dev]

Merci pour la réponse

Les constantes doivent être là où elles doivent être.

Je suis d'accord mais dans mon cas, j'avais des constantes réutilisées par plusieurs modules [une trentaine] donc je trouvais logique de les "externaliser" pour éviter les incohérences.

Je vais utiliser le principe de la méthode pour gérer cela.