[java] adresse d'une String
Fermé
batmat
Messages postés
1871
Date d'inscription
jeudi 1 novembre 2001
Statut
Membre
Dernière intervention
9 janvier 2008
-
3 oct. 2003 à 15:45
plop! Messages postés 54 Date d'inscription jeudi 1 février 2007 Statut Membre Dernière intervention 16 mai 2007 - 11 mai 2007 à 03:35
plop! Messages postés 54 Date d'inscription jeudi 1 février 2007 Statut Membre Dernière intervention 16 mai 2007 - 11 mai 2007 à 03:35
A voir également:
- [java] adresse d'une String
- Waptrick java football - Télécharger - Jeux vidéo
- Darkino nouvelle adresse - Guide
- Jeux java itel football - Télécharger - Jeux vidéo
- Adresse mac - Guide
- Créer une adresse hotmail - Guide
1 réponse
plop!
Messages postés
54
Date d'inscription
jeudi 1 février 2007
Statut
Membre
Dernière intervention
16 mai 2007
27
11 mai 2007 à 03:35
11 mai 2007 à 03:35
Ce n'est pas pour répondre à batmat (car le topic date de 2003), mais parce que je me posais la question, et que je n'ai trouvé que cette question sans réponse sur ce forum.
Aussi, le prochain qui cherchera (in y en a ?), trouvera sa réponse.
Il n'y a, en théorie, aucun moyen de connaître l'adresse mémoire d'un objet Java, sauf qu'il existe une fonction particulière :
System.identityHashCode(Object o)
Elle appelle la fonction native Object.hashCode() sur l'objet o (et non celle éventuellement surdéfinie). Et il se trouve qu'actuellement toutes les implémentations des JVM retournent l'adresse mémoire de l'objet.
Mais il peut exister quelque part dans ce bas monde (surtout maintenant qu'il est OpenSource) une JVM qui ne souhaite pas procéder ainsi. Et elle aurait raison, car voici le rapport de bug, et la documentation de SUN traitant du problème que cela soulève :
Rapport de bug : https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6321873
Documentation : https://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#hashCode()
Pour les flemmards, il en résulte que System.identityHashCode() ne peut pas servir à identifier un objet de façon unique (surtout sur un système 64 bits).
Une méthode pour identifier un objet de façon unique (car c'était là mon problème à la base), est de créer sa propre classe :
A noter, qu'il suffirait même de retourner le BigInteger ID à la place d'une String, car ils sont tous uniques.
Cette classe résoud non seulement les problèmes de non unicité de System.identityHashCode() mais empêche également la réutilisation d'un identifiant déjà attribué à un objet détruit (par le GC).
plop!
Aussi, le prochain qui cherchera (in y en a ?), trouvera sa réponse.
Il n'y a, en théorie, aucun moyen de connaître l'adresse mémoire d'un objet Java, sauf qu'il existe une fonction particulière :
System.identityHashCode(Object o)
Elle appelle la fonction native Object.hashCode() sur l'objet o (et non celle éventuellement surdéfinie). Et il se trouve qu'actuellement toutes les implémentations des JVM retournent l'adresse mémoire de l'objet.
Mais il peut exister quelque part dans ce bas monde (surtout maintenant qu'il est OpenSource) une JVM qui ne souhaite pas procéder ainsi. Et elle aurait raison, car voici le rapport de bug, et la documentation de SUN traitant du problème que cela soulève :
Rapport de bug : https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6321873
Documentation : https://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#hashCode()
Pour les flemmards, il en résulte que System.identityHashCode() ne peut pas servir à identifier un objet de façon unique (surtout sur un système 64 bits).
Une méthode pour identifier un objet de façon unique (car c'était là mon problème à la base), est de créer sa propre classe :
import java.math.BigInteger; abstract public class Identifiable implements java.lang.Cloneable { private static BigInteger count = BigInteger.ZERO; private BigInteger ID = null; public String uniqueID() { if(ID == null) { ID = Identifiable.count = Identifiable.count.add(BigInteger.ONE); return getClass().getName()+"@"+ID; } public Object clone() throws OutOfMemoryError { Identifiable copy; try { copy = (Identifiable) super.clone(); copy.ID = null; return copy; } catch (CloneNotSupportedException ex) { throw new InternalError(ex.toString()); } } }
A noter, qu'il suffirait même de retourner le BigInteger ID à la place d'une String, car ils sont tous uniques.
Cette classe résoud non seulement les problèmes de non unicité de System.identityHashCode() mais empêche également la réutilisation d'un identifiant déjà attribué à un objet détruit (par le GC).
plop!