Discussion :

[Guybrush]

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 ?

[thelvin]

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.

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.

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.

[Guybrush]

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.

[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.

[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 ...

[adiGuba]

Salut,

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++

[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.