Problèmes avec les variables final

**casolaro** · 09/12/2004, 11h03

Bonjour à tous...

Je développe est java depuis bientôt deux ans, et récemment, j'ai été confronté à un petit problème du style "effet de bord" qui énerve assez.
J'ai identifié le problème qui vient apparamment du compilo qui ferait des optimisations parfois inconvenantes... Pour mieux comprendre je vous expose le problème par deux petites sources et je vous détaille le tout.

Il faut créer un premier paquetage que l'on appelera "librairie" et qui contient une classe Lib décrite comme suit:

Code :

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

1
2
3
4
5
6
7
8
9
10
package librairie;
 
public class Lib{
   public final static String CONSTANTE = "Ma constante";
 
   public static void methode(String arg) {
      System.out.println("librairie.Lib.methode: arg = "+arg);
      System.out.println("librairie.Lib.methode: CONSTANTE = "+CONSTANTE);
   }
}

Ensuite vous créez un second paquetage appelé "application" qui contient la classe Application décrite ci après:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
package application;
 
import librairie.Lib;
 
public class Application {
   public static void main(String args[]) {
      System.out.println("application.Application: Lib.CONSTANTE = "+Lib.CONSTANTE);
      System.out.println("application.Application: Appel de la méthode de la librairie.\n");
      Lib.methode(Lib.CONSTANTE);
      System.out.println("\napplication.Application: Fin");
   }
}

Vous compilez le tout et tout marche comme prévu...

Maintenant, imaginez que vous voulez modifier la constante CONSTANTE dans la librairie: vous modifier le code de Lib.java et vous affectez "Ma nouvelle constante" à la variable constante... Cependant, vous ne recompilez que le paquetage librairie parce que vous pensez que la modification va être impactée sur l'application...
Ben non!!!

Relancez application.Application après n'avoir recompilé que la librairie et une chose bien étrange vous surprendra...

Apparemment, le compilo transfère toutes les constantes dans les classes qui les utilisent pour optimiser le code. Actuellement, les moyens de s'en sortir sont de ne pas déclarer ces constantes en véritables constantes (supprimer final

), ou de faire un accès aux valeurs par des méthodes: ce qui n'est pas très optimal

!!! Un autre moyen serait de gérer les sources java par un makefile comme pour le C et le C++: mais on perd en souplesse

!!!

:

:
Alors la question que je pose c'est la suivante: existe-t-il une option de compilation ou une classe de mémorisation qui permette d'obtenir le résultat voulu sans trop dégrader les performances du code et sans ajouter trop de contrainte?

:

Ceci est quand même assez remarquable. Imaginez que vous fournissez une librairie d'objets java qui contiennent des constantes publiques. Votre client compile une première fois son application avec vos classes et tout marche très bien. Quelques temps après vous livrez une nouvelle version de votre librairie. Votre client l'installe, mais ne recompile pas son application parce que vous lui avez indiqué que les modifications ne nécessitent pas de recompilation... Et là, pof, plus rien ne marche!!!

Merci à tous ceux et à toutes celles qui pourront m'éclairer sur le sujet!!!

A bientôt

**Marc_P** · 09/12/2004, 11h32

Le théorie des compilateurs et des linkers, ça t'évoque quelque-chose? ;-)
l'import ne se fait pas à l'exécution, mais à la compilation.
Si tu veux pouvoir changer ta constante (qui du coup, devient une variable, non?), pourquoi ne pas utiliser un fichier de properties?

**adiGuba** · 09/12/2004, 11h39

Salut,

En effet, il s'agit d'une optimization du compilateur. Il considère qu'une constante ne devrait pas être modifié...
si il s'agit de paramètres de l'application, je pense comme Marc_P qu'il vaut mieux utiliser un fichier de configuration (properties, XML ou autres...)

Mais il existe quand même une solution pour éviter que le compilateur n'effectue l'optimization : il ne faut pas définir la valeur avec l'opérateur egal mais dans un bloc static{}.
Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public class Lib{
	public final static String CONSTANTE;
	public final static String CONSTANTE2;
 
	static {
		CONSTANTE = "Ma Constante";
		CONSTANTE2 = "Ma Constante 2";
	}
 
	/*...*/
}

Par contre je ne sais pas si c'est mieux ou pas que l'utilisation de méthode getter...

Les variables static final ne seront plus remplacées par leurs valeurs à la compilation...
Il faut bien sûr recompiler le tout au moins une fois après la modif...

a++

**jerome.petit** · 09/12/2004, 11h56

Par rapport à la méthode getter, en termes de performances tu gagnes un appel de fonction.

**casolaro** · 09/12/2004, 12h20

Merci à tous pour vos tuyaux...

En ce qui concerne le fichier de properties, la méthode n'est pas acceptable puisque ces derniers sont facilement accessibles aux utilisateurs peu scrupuleux...

Merci à adiGuba pour son astuce sur l'initialisation par blocks, je crois que dans un premier temps c'est ce que je vais faire!!!

En tous les cas, ce forum est très efficaces!

I'll be back

**Pill_S** · 09/12/2004, 14h16

c'est peut-être bête comme idée, mais peut-être que cela ne réagit pas pareil en utilisant des interfaces pour les constantes ? as-tu essayé ?

**casolaro** · 09/12/2004, 14h22

Non, j'ai pas testé le coup des interfaces...
Je vais m'y attacher... Mais je ne vois pas pourquoi le compilo ne ferait pas le même type d'optimisation...