Déclaration des constantes

Version imprimable

31/03/2011, 12h53
Guybrush

Déclaration des constantes

Pour déclarer une constante dans une classe Java, j'utilise la syntaxe suivante :
private final static int CONSTANTE = 5

La question que je me pose est la suivante :
est ce que le compilateur effectue réellement le remplacement de toutes les utilisations de cette constante pour par sa valeur ?

Je demande ça car si je décompile le .class produit par la compilateur, la déclration de la constante est tjs présente (j'ai pourtant compilé avec l'option d'optimisation)
N'y aurait-il pas moyen de réduire la taille des .class en supprimant la déclaration ? surtout lorsque celle-ci est marqué en private ?
31/03/2011, 14h18
thelvin

Citation:

Envoyé par Guybrush

La question que je me pose est la suivante :
est ce que le compilateur effectue réellement le remplacement de toutes les utilisations de cette constante pour par sa valeur ?

Oui. Ça aussi, ça devrait se voir, en décompilant la classe.

Citation:

Envoyé par Guybrush

Je demande ça car si je décompile le .class produit par la compilateur, la déclration de la constante est tjs présente (j'ai pourtant compilé avec l'option d'optimisation)

Les constantes sont aussi des variables membres accessibles par réflexion, elles doivent donc figurer dans la classe.

Citation:

Envoyé par Guybrush

N'y aurait-il pas moyen de réduire la taille des .class en supprimant la déclaration ? surtout lorsque celle-ci est marqué en private ?

Pas à ma connaissance. À la limite tu pourrais juste mettre toujours 5 à la place de CONSTANTE : c'est moche mais ça marche.
Autre possibilité : faire une autre classe qui contienne ces constantes et t'en servir dans la classe en cours : après compilation il n'y aura aucune trace d'elles dans la classe en cours... Mais il semble qu'une dépendance de la classe en cours vers la classe à constantes soit maintenue, même si elle ne sert à rien.

Bon, et enfin, "réduire la taille" ? 'Faut pas déconner non plus. Le nombre de variables qui puissent être déclarées dans une classe est limité. Si tu n'atteins pas ce nombre, ce genre d'économies de bout de ficelles est risible. Si tu atteints ce nombre, la classe ne compilera pas.
31/03/2011, 14h35
Guybrush

Citation:

Envoyé par thelvin

Bon, et enfin, "réduire la taille" ? 'Faut pas déconner non plus. Le nombre de variables qui puissent être déclarées dans une classe est limité. Si tu n'atteins pas ce nombre, ce genre d'économies de bout de ficelles est risible. Si tu atteints ce nombre, la classe ne compilera pas.

Pour une appli desktop on est d'accord. POur une appli mobile c'est beaucoup moins vrai. Pour Android par exemple, un "gros" fichier class peut avoir de grosse conséquence :
- temps de conversion au format dalvik plus long.
- Taille du binaire dex généré plus gros.
31/03/2011, 14h41
Uther

Quand je bossais dans les jeux JavaME, on utilisait plusieurs outils pour obfusquer le code et faire ce genre d'optimisations, c'est d'autant moins gênant en JavaME, ou il n'y a pas d'introspection. Attention, certains un peu violent nous ont parfois conduit a des bug bizarres.

Je ne me souvient plus que de Proguard, mais il on en avait d'autres.
04/04/2011, 09h51
Logan Mauzaize

Il me semblerait étrange qu'une constante déclaré dans une classe et réutilisée ailleurs soit remplacée par sa valeur ... Si tu recompiles la classe qui définit la constante le code ne marcherait plus ...
04/04/2011, 10h53
adiGuba
Salut,

Citation:

Envoyé par Nemek

Il me semblerait étrange qu'une constante déclaré dans une classe et réutilisée ailleurs soit remplacée par sa valeur ... Si tu recompiles la classe qui définit la constante le code ne marcherait plus ...

C'est pourtant bien le cas. Cf la FAQ : Qu'est-ce qu'une constante ?

@Guybrush : C'est normal que le champ static correspondant ne soit pas supprimé du fichier .class, pour deux raisons :
- Le compilateur doit bien pouvoir accéder à cette information pour remplacer la valeur.
- On pourrait vouloir accéder aux informations via l'API de reflection...
a++
04/04/2011, 10h57
Uther

C'est pourtant bien le cas.

C'est pour cela que quand on modifie une constante, il faut penser a recompiler toutes les classes qui utilisent cette constante sous peine d'erreur parfois pas évidente à comprendre.
04/04/2011, 10h59
adiGuba

Une constante ne devrait pas être modifier, ou alors cela ne devrait pas avoir d'impact significatif sur le programme...

a++
04/04/2011, 11h33
Logan Mauzaize
Autant pour des constantes numérique je veux bien mais pour des constantes de type "chaîne" je trouve ça limite.

Je prend un exemple qui nous est arrivé. Pour un framework web (codé avec les pieds par des stagiaires), on a des constantes qui définissent de nom de variables de session. Les valeurs des constantes ont été changées car trop générique (ex: "user").

Du coup j'ai une question: Si je fais ça, est-ce une constante ?
Code:

1 2 public static final String MA_CONSTANTE = new String("MA_VALEUR");
?
04/04/2011, 11h45
adiGuba
Ben les constantes fonctionnent comme cela... que ce soit pour les types primitifs ou pour les chaines.

D'ailleurs au passage sur les string c'est très intéressant car cela permet d'effectuer les concaténations dès la compilation ;)

Enfin si c'est des constantes utilisé dans une même appli ce n'est pas bien méchant, il suffit de tout recompiler pour être sûr ;)
Citation:
Envoyé par Nemek

Du coup j'ai une question: Si je fais ça, est-ce une constante ?

Code:

1 2 public static final String MA_CONSTANTE = new String("MA_VALEUR");

?
:arrow: Il y a un appel de constructeur, donc ce n'est pas une constante...

a++
04/04/2011, 11h58
Logan Mauzaize
Bah justement je trouvais ça bizarre pour des API / Framework. Je me demanderai plus pourquoi ils ont pas changé des valeurs de constantes mal foutues ...

Je garde également à l'esprit la méthode alternative, certes bien moches. Pour générer de fausses constantes.

Et un truc du genre :
Code:

1 2 3 4 5 6 7 8 9 10 public static final int UN; public static final int DEUX; public static final int QUATRE; static { UN = 1; DEUX = UN + UN; QUATRE = DEUX * DEUX; }
05/04/2011, 14h28
thelvin
Je ne vois toujours pas l'intérêt de faire des "fausses constantes," mais si je voulais en faire, ce serait ainsi :
Code:

1 2 3 4 5 6 7 public class NonConstant { public static int of(int i) { return i; } // ... }
Code:

1 2 // ailleurs public static final int DIGITS = NonConstant.of(10);
Cela a le mérite d'exprimer sémantiquement le pourquoi de cette pirouette.
05/04/2011, 15h33
Logan Mauzaize

Citation:

Envoyé par thelvin

Je ne vois toujours pas l'intérêt de faire des "fausses constantes,"

Pour les raisons évoqués ci-dessus

Citation:

Envoyé par Nemek

Pour un framework web (codé avec les pieds par des stagiaires), on a des constantes qui définissent de nom de variables de session. Les valeurs des constantes ont été changées car trop générique (ex: "user").

Citation:

Envoyé par Nemek

Bah justement je trouvais ça bizarre pour des API / Framework. Je me demanderai plus pourquoi ils ont pas changé des valeurs de constantes mal foutues ...
05/04/2011, 17h45
thelvin

Je ne vois toujours pas, c'était une invitation à t'expliquer si tu penses tenir quelque chose...

Quand on s'amuse à patcher des classes compilées sans recompiler le tout, on est censé savoir à quoi on s'expose, hein.
05/04/2011, 19h06
adiGuba

@thelvin : sur une application standalone ce n'est pas un soucis : tu modifies ta "constante" et tu recompiles tout.

Mais si tu développes une librairie externe tu n'as pas la main sur tous les codes qui utilises ta librairie, et donc la modification n'est pas forcément effectué.

Mais à la base c'est un problème de conception : la valeur n'est pas une constante mais plutôt une variable immuable. Un méthode static aurait été un bien meilleur choix qu'une constante...

a++
06/04/2011, 09h37
Logan Mauzaize

Citation:

Envoyé par adiGuba

Mais à la base c'est un problème de conception : la valeur n'est pas une constante mais plutôt une variable immuable. Un méthode static aurait été un bien meilleur choix qu'une constante...

Je dirais que le problème c'était surtout le choix des valeurs -_-'
Cependant je ne vois pas un problème de conception mais de codage/technique/méconnaissance des mécanismes de compilation Java. Tu déclares un attribut (static et final sont là à mon sens pour que ne se soit pas lié par une instance et pour protéger l'attribut) et tu créées des dépendances sur cet attribut en l'utilisant.
06/04/2011, 10h47
thelvin

Mouais. Changer la valeur d'une constante exposée, c'est changer l'API exposée.
Il est certes malheureux que cela n'empêche pas le linking avec du code compilé pour la précédente API, mais fondamentalement c'est la même chose qui si on change le comportement d'une méthode exposée sans changer sa signature.
06/04/2011, 10h50
Logan Mauzaize

Citation:

Envoyé par thelvin

Mouais. Changer la valeur d'une constante exposée, c'est changer l'API exposée.
Il est certes malheureux que cela n'empêche pas le linking avec du code compilé pour la précédente API, mais fondamentalement c'est la même chose qui si on change le comportement d'une méthode exposée sans changer sa signature.

Je dirais changer l'implémentation sans changer le comportement ... Sauf que ce qui se produit c'est ce que tu dis :( Néanmoins ca doit être un petit mal (ca arrive très rarement) pour un grand bien (en terme d'optimisation)