vraiment ... personne a d'idée ???
ils devaient bien avoir une raison les dev de chez sun !!
benou
DarkLord a écrit a écrit :
pas bete. De plus synchronized sur une String ... bof
:??: hein ?
benou
alien_nan a écrit a écrit :
Allez, je prends un risque :
si tu as une autre classe qui appelle cette methode pendant qu'il est en train de calculer ta hashcode, n'y a t-il pas un risque, meme infime, que value puisse changer ?
donc a ce moment la, en le stockant dans une variable locale, tu n'as plus le risque de voir ta variable value changer.
Et un essai, un :)
ben non ... pourquoi ca changerait ? String est immuable !
et puis en plus, si value change, val va changer aussi puiqu'ils pointent tous les deux sur le même objet ...
darklord
pas bete. De plus synchronized sur une String ... bof
alien_nan
Allez, je prends un risque :
si tu as une autre classe qui appelle cette methode pendant qu'il est en train de calculer ta hashcode, n'y a t-il pas un risque, meme infime, que value puisse changer ?
donc a ce moment la, en le stockant dans une variable locale, tu n'as plus le risque de voir ta variable value changer.
Et un essai, un :)
benou
salut tout le monde.
Je viens de regarder le code source de la classe String et y a un truc que je capte pas dans l'implémentation de la méthode HashCode.
voici son code (jdk 1.3) :
Code :
publicint hashCode() {
int h = hash;
if (h == 0) {
int off = offset;
char val[] = value;
int len = count;
for (int i = 0; i < len; i++)
h = 31*h + val[off++];
hash = h;
}
return h;
}
la question que je me pose c'est : à quoi ca sert de déclarer les variables val et len ??? pourquoi ne pas avoir tout simplement utilisé les variables value et count ??? Les objets String sont immuables, donc de toute façon les valeurs de ces variables ne changerons pas. Doit bien y avoir une raison ...
