Delta(Canard.java) => Delta(Mare.class)

Mise en place

Fichier Canard.java

Code:

---

1 2 3 4

public class Canard { public static final String CRI = "Coin ! Coin !"; }

---

Fichier Mare.java

Code:

---

1 2 3 4 5 6

public class Mare { public static void main(String[] arguments) { System.out.println("Le canard dit : " + Canard.CRI); } }

---

Manipulation

1) javac Mare.java

-> Les deux fichiers Java sont compilés.

2) java Mare

-> Affiche "Le canard dit : Coin ! Coin !"

4) Changement de "Coin ! Coin !" en "Miaou !" dans le fichier Canard.java.

5) javac Canard.java

-> Seul Canard.java est compilé.

6) java Mare

-> Affiche "Le canard dit : Coin ! Coin !"

7) rm Mare.class

-> Affiche "Le canard dit : Coin ! Coin !"

Conclusion :

La constante CRI n'est visiblement par référencée, mais sa valeur directement "embarquée" dans les classes qui l'utilisent (ici la Mare.java). A ma connaissance, il s'agit du seul cas où une modification dans un fichier *.java se répercute sur d'autres *.class que le sien (ou les siens dans le cas de classes internes).

Question :

Existe-t-il d'autres cas de figures et, idéalement, un principe général ?

quand une variable est static, public, final, le compilateur la considère comme une constante, et pour des raisons de performance, embarque directement la valeur de la constante plutot que de référencer la classe.

En pratique, peut d'impact comme mentionné puisque, tout bon développeur, fait un clean de son projet avant de faire une release :lol:


Autre cas possible: classe java avec date de modification dans le passé.

Exemple:

1) Xxx.java récupéré d'un svn
3) fait un changement
4) compile
5) efface le java et récupère le svn
6) oublie d'effacer le .class -> on est toujours en binaire à la version modifiée ;)

Salut,

Citation:

---

Envoyé par tchize_

quand une variable est static, public, final, le compilateur la considère comme une constante,

---

Pas tout à fait. static et public n'ont rien à voir avec cela...

En plus d'être déclarée final, une constante est définie par trois critères :

• L'attribut doit correspondre à un type primitif ou au type String.
• Il doit être initialisé en ligne à la déclaration.
• Il doit pouvoir être évalué à la compilation.

Dès lors le compilateur se chargera de remplacer le champ par sa valeur partout où elle se trouve. Il est donc impératif d'éviter d'utiliser des constantes pour des champs qui risque de changer. En particulier dans le cas d'une API tierce...


Dans les fait on constate surtout cela dans un attribut public static, mais ce n'est pas forcément le cas. Par exemple :

Code:

---

1 2 3 4 5 6 7 8

public class Canard { final String cri = "Coin ! Coin ! Coin !";   public String getCri() { return cri; } }

---

Code:

---

1 2 3 4 5 6 7

public class Mare { public static void main(String[] arguments) { System.out.println("Le canard dit : " + new Canard().getCri()); System.out.println("Le canard dit : " + new Canard().cri); } }

---

:arrow: La première ligne sera toujours correct (car la méthode getCri() est logiquement recompilé en même temps que sa classe ;)). Par contre la seconde ligne peut rencontrer le même soucis car le compilateur remplace l'accès à l'attribut par la valeur de la constante ;)


a++