L'identité des instances d'une class que j'ai créé est faite par 5 entiers. Sachant que ceux-ci ne sont pas bornés, vous voyez un moyen de calculer un hashcode de ces objets ?

Euh, reponse bateau, mais :
 
Pourquoi ne pas faire un String :
String taString = ""+entier1+enteri2....
 
avec tes 5 entiers et appeler taString.hashCode() ?

C'est sans doute ce que je vais faire, parce que je vois pas d'autre possibilité.
Par contre dans la soluce que tu me propose, il manque qqch :
iMonentier1=1 et iMonEntier2=11
sera considéré de la même façon que iMonentier1=11 et iMonEntier2=1
Il faut donc avant que la réprésentation ss forme de String comporte toujours le même nombre de chiffres (0 devant si nécessaire).
Merci.

Bin faut utiliser un algo de hash
Mate dans javax.security, y a MessageDigest qui fera c'que tu cherches avec un algo type MD5. Maintenant, MD5 c'est p'têt un peu violent, je sais pas.

 
MD5 c'est pas pour du codage ?

 
non, c'est pour du hash

MD5 est un algorithme de hashage. Il est souvent utilisé avec Random et d'autres trucs pour obtenir des UUID mais il n'a pas pour vocation de crypter/décrypter des données.
Mate un peu sur Gougueule, tu verras bien

 
Mais j'te crois, t'emballe pas !

Mais en fait, je vois pas comment utiliser MessageDigest

 
C comme ça que ça marche ?

Euh, je ferais plutot comme ca:
 

 
 
Sinon, tu utilises seulement ie5 pour hasher...

C'est pas facile
Cherche des exemples de code sur l'Net ou même sur le forum, j'me souviens que la question avait été posée. C'était pour calculer un UUID mais y a la méthode pour récupérer ton hashcode sous forme de String.

Tiens, je viens de retrouver un vieux bout de code dans lequel je crypter en MD5 avant de faire une insertion MySQL ( avant de découvrir qu'il existe une fct MD5() dans MySQL !!
 

Heu, si t'as pas envie de te faire chier tu peux aussi faire plus simple avec la moyenne des 5 entiers ou tout autre combinaison plus ou moin linéaire.

 
C pas nécessairement vrai:
 

 
Edit: En y repensant y a un truc qui me chiffonait, et heuresument la méthode est surchargée au niveau des String  

ca suffira dans la plupart des cas ...

Mais en fait je me suis peut être mal exprimé. Je suis pas sur que ce soit un hashcode que je recherche.
La seule chose que je veux, c'est un identifiant, sachant que :
2 objets ayant au moins 1 des 5 entiers caractéristiques différents n'auront jamais le même identifiant.
2 objets ayant les mêmes valeurs pour ces 5 entiers auront toujours le même identifiant.

Ou alors tu imprimes ces nombres dans un String avec le signe et un nombre fixe de chiffres chacun (10 pour un int). C'est plus lent, mais plus fiable.

 
Merci, mais c'est ce que j'ai dis que j'allais surement faire (cf mon 2e post).
Par curiosité (et soucis d'optimisation), je cherche qd même une soluce par les entiers...

Si si, c'est bien un hashCode qui pourra te faire l'affaire, pourvu qu'il soit implémenté conformément à la documentation de la méthode hashCode de la classe java.lang.Object.

tain faut s'calmer ici, un hashCode d'entiers calculé avec un MessageDigest

 
ça bouffe des ressources un MD5 ?
Et, sinon, t'as une solution toi ?

 
Nan, la doc indique expressément qu'il n'est pas nécessaire que le hashcode de deux objets non égaux n'est pas nécessairement différent.

ben c'est surtout que ça a pas de rapport quoi
 
moi je ferais un truc dans le genre de ce que benou à proposé, eventuellement en donnant plus de poids à l'un ou l'autre des entiers selon ta logique... si c'est pour foutre les trucs dans une hashmap par exemple, c bon.. si tu redefinis aussi equals()  
 
...mais ça depend ce que tu veux faire de ton truc

Ba tout dépend de l'utilisation, hein
On demande du hashcode, j'sors la possibilité d'utiliser un algo de hash, c'est tout. Maintenant, si c'est pour un truc tout con qui doit tenir dans un int, effectivement y a mieux, mais pour un truc industriel dont la fiabilité sera requise avant tout, bin vaut mieux passer par des trucs sur 128 bits
 
Gringo : ui, ça bouffe des perfos, je crois. Maintenant, à toi de voir ce dont tu as besoin. Apparemment, c'est un identifiant unique mais faut voir dans quel contexte tu l'utiliseras.

ben ui, un hashCode quoi
(ou alors j'ai rien compris )

 
Nan, le truc de benou, ça me va pas. En pnodérant l'un ou l'autre des entiers non plus.
Cf mon post :
 

ben en ponderant les 5 entiers differement, en fonction de leur valeur max, ça peut le faire, si tu veux ABSOLUMENT que ta 1e regle soit respectée
 
tu dis tjs pas à quoi va te servir cet id...

Heu, tu fais une classe Identifiant où tu remet les 5 entiers et tu surcharge equals?

Attention à la fracture du neurone les gens dans ce topic.

 
grilled

 
J'ai précisé au début qu'aucun de ces entier n'est pas borné -> pas de la valeur max (ou moins tous la même : celle d'un int).
 

 
Parce que ça change pas grand chose, si !?
Enfin, si tu veux. Ces objets sont des Bean, récupérés depuis une base de donnée. Chaque bean correspond à un enregistrement dans une table en bd. Dans cette table, l'unicité de chaque enregistrement est assurée par 5 champs de type int. je veut reproduire ça dans mon bean, et pouvior identifier un enregistrement. Voila.

 
T'as une idée Einstein ?

Fais un résumé clair de ton problème vu qu'apparement il a changé au cours du topic. Mais je sens à plein nez que ça va se finir par 4 additions.

 
Le problème n'a pas changé.
Tu veux bien foutre 30 Secondes tes airs supérieurs au placard ?
 
Ennoncé on n'peux plus clair (tu tailles sans même savoir ce qu'on cherche à faire !? :

 
si tu veux assurer l'unicite, c'est pas un hashcode, et la seule facon c'est de definir une application bijective qui a 5 entiers en associe 1. Un int etant sur n bit en java (je mets n parce que je ne suis pas sur, je crois que c'est 16), il te faut 5n bits a l'arrivee.  
apres, il y a une foultitude de bijections, la plus simple etant de mettre les bits bout a bout

 
C'est 32 bits le int en java

alors il va falloir 160 bits

et alors ? ca respecte la règle du hashcode ...  
 
j'avais pas compris que ce qu'il voulait n'était pas ce qu'il avait demandé

T'as pas le choix t'es obligé de garder tes 5 entiers.
 
si tu avais viré la première règle, alors hashCode() servait à ça, en faisant 4 additions (pour rappel, les int java sont modulaires, c'est à dire qu'on peut les additionner tant qu'on veut, si on va plus loin que le plus grand représentable, ça "fait le tour" http://java.sun.com/docs/books/jls [...] html#51035 )
 
Concernant, ton problème, tu mets le code de Benou dans hashCode()
 
et dans equals tu mets  

 
Et tu utilises systématiquement equals() pour savoir si 2 instances sont pareilles.
 
Et tes instances sont leur propres identifiants.