[JAR]Constantes Java [Infos]

**Coulon Arnaud** · 20/01/2005, 15h36

Bonjour,

j'ai l'impression que lors de la compilation du code Java, les constantes sont remplacées par leurs valeurs.

Pb : En simplifiant
Utilisation de 2 jars (1 contenant les constantes et 1 autre faisant appel à ces constantes).
Si je modifie les valeurs des constantes et que je recompile le jar contenant les constantes, l'autre jar ne prend pas en compte les modifications.
Pour que les modifications soient prises en compte, il faut que je recompile le jar faisant appel à ces constantes.

Est ce normal ?
Y a t'il une solution pour éviter d'avoir besoin de tous recompiler ?

merci par avance

Arnaid

[Modéré par Didier]
Ajout de tag dans le titre
Lire les règles du forum : Règles du forum Java

**thibaut** · 20/01/2005, 15h38

Oui c'est exact, les constantes sont remplacées par leurs valeurs lors de la compilation de tes classes...

TU pourrais essayer d'externaliser tes constantes dans un fichier xml ou properties...

**nuke_y** · 20/01/2005, 15h48

Euh attends là ...
si tu as

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public class MesConstantes
{
   public int MA_CONSTANTE = 1;
}
 
public class MaClasse
{
   public MaClasse()
   {
       int maVar = MesConstantes.MA_CONSTANTE;
   }
}

Si tu changes la valeur de MA_CONSTANTE et que tu lui donnes 2 au lieu de 1 et que tu recompiles le fichier MesConstantes SANS recompiler MaClasse, tu auras toujours maVar = 1 ???? je crois pas ...

**Coulon Arnaud** · 20/01/2005, 15h51

C'est ce qui m'arrive !

**Coulon Arnaud** · 20/01/2005, 15h53

Ce n'est pas trop lourd pour les performances de passer par le chargement de fichier xml ou deproperties ?

Arnaud

**nuke_y** · 20/01/2005, 15h56

attends je teste parce que là j'y crois pas !!

**thibaut** · 20/01/2005, 15h57

Ben non absolument pas, un l'exploitation d'un .properties ou d'un .xml se fait trés facilement et selon le parser l'exploitation du xml est plus ou moins efficace...

De plus il est conseillé d'externaliser au maximum les constantes...

Imagines que tu aie ces deux classes dans deux jars différents:

jar1

Code :

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

1
2
3
4
public class MesConstantes 
{ 
   public int MA_CONSTANTE = 1; 
}

jar2

Code :

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

1
2
3
4
5
6
7
public class MaClasse 
{ 
   public MaClasse() 
   { 
       int maVar = MesConstantes.MA_CONSTANTE; 
   } 
}

A la compilation dur jar2 tu as

Code :

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

1
2
3
4
5
6
7
public class MaClasse 
{ 
   public MaClasse() 
   { 
       int maVar = 1; 
   } 
}

Or si tu changes MA_CONSTANTE de 1 en 2 et que tu ne recompile pas le jar2 et bien tu auras un décalage... IL faut faire une sorte d'édition de liens un peu comme les makefile du c, tu peux gérer ça avec Ant...

**nuke_y** · 20/01/2005, 16h08

attends je teste parce que là j'y crois pas !!

**plopinou** · 20/01/2005, 16h08

Tu peux aussi supprimer le bug en recompilant toutes tes classes à chaque fois. Mais le mieux est quand même d'externaliser tes constantes dans un fichier properties ou xml.

**nuke_y** · 20/01/2005, 16h17

Dites euh j'ai vérifié et je suis pas d'accord. Soit y a quiproquo soit y a bug !! Parce que chez moi :

Code :

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

1
2
3
4
5
public class MesConstantes
{
  public static int MA_CONSTANTE=1;
 
}

dans le fichier constantes.jar

et

Code :

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

1
2
3
4
5
6
7
public class TestMesConstantes
{
  public static void main(String[] args)
  {
  	System.out.println("Valeur ="+MesConstantes.MA_CONSTANTE);
  }
}

dans le fichier testconstantes.jar

donne:

Valeur=1

si je l'exécute comme ça :

Code :

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

java -cp mesconstantes.jar;testmesconstantes.jar TestMesConstantes

et si je change la valeur et que je met

Code :

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

1
2
3
4
5
public class MesConstantes
{
  public static int MA_CONSTANTE=2;
 
}

dans le fichier constantes.jar SANS toucher à testconstantes.jar et que je relance le tout j'obtient bien

Valeur=2

Es-tu sûr que tes jar sont bien écrasés à chaque modification ??

**lionelBadiou** · 20/01/2005, 16h20

Juste en passant...

Ca donne le tourni d'externaliser des constantes pour avoir la possibilité de changer leur valeurs

.Si les constantes deviennent des variables, on ne peut plus se fier à rien !

Cela dit, le remplacement d'une constante par sa valeur est censé être une optimisation du compilateur (pas d'emplacement mémoire utilisée) mais abouti à ce genre d'imprévu.

Bonne journée,
----------------------------------
Lionel Badiou
CodeFutures -
Java Code Generation

http://www.codefutures.com

**nuke_y** · 20/01/2005, 16h27

On externalise des constantes quand on a pas le temps de se faire chier à faire un .property ou un xml. C'est une bonne façon de tester rapidement en recompilant juste les paramètres diverses configuration sans devoir les passer en paramètre à un main.
CEPENDANT c'est une solution temporaire qui doit être rapidement remplacées par un property ou un xml.

Le fait de passer D'ABORD par un fichier de constantes externalisé permet cependant de mieux appréhender le passage en fichier de paramètre. Après c'est un choix, rien d'obligatoire.

Pour terminer je vois pas comment la valeur d'un attribut d'une classe située dans un jar peut être remplacée par une constante lors de la compilation d'un autre jar... Si effectivement ça existe, c'est pas très très malin... Dans ce cas on met tout dans le même jar !

**Coulon Arnaud** · 20/01/2005, 16h28

Rajoute final pour faire le test :

public static final int MA_CONSTANTE=1;

**nuke_y** · 20/01/2005, 16h33

ah oui avec final forcément ! Je crois que c'est le but de final, de ne pas permettre d'autre valeur pour une constante que celle de la compilation et de ne pas pouvoir être surchargée par une classe fille...

EDIT:
Et je confirme avec le test, final fige bien la valeur à la compilation.

**plopinou** · 20/01/2005, 16h53

CEPENDANT c'est une solution temporaire qui doit être rapidement remplacées par un property ou un xml.

Pas forcément. Il arrive que parfois, on ne veut pas de constantes en dehors du programme dans un fichier xml ou properties. Par exemple, une valeur à laquelle on interdit la modification ou même la consultation par l'utilisateur. J'ai un exemple concret sous la main : un programme qui se connecte à une BD, mais dont on ne veut pas que les codes d'accès soient visibles, ni même modifiables.

**nuke_y** · 20/01/2005, 17h05

Tu vas rire mais j'ai EXACTEMENT le même exemple. J'ai mis les constantes dans une classe à part comme ça mon boss à qui je laisse le projet a juste à modifier cette classe, à cliquer sur CP.bat et create_jar.bat puis à remplacer le jar et c'est bon. Mais comme le disait un ami à moi, une bonne décompilation et c'est finit donc ... En tout cas elles ne sont pas en final mes constantes.