Déterminer l'adresse d'une instance

Zouplaz wrote:

Black Myst - Black_point_Myst_chez_free_point_fr :

Zouplaz wrote:

Bonjour, j'ai besoin de connaitre l'adresse d'une instance...

Seule le GC peut connaitre cette information, d'ailleur il a meme la
possibilité de deplacer l'objet en mémoire pour "tasser le tas".

L'@ mémoire d'une instance n'a aucun interet... Que souhaites tu faire
?

Distinguer deux instances dans les log. J'ai une classe, dont deux
instances sont créées par un framework. Je log tous les appels mais comment
distinguer une instance d'une autre pour retracer la séquence d'exécution
des méthodes ? C'est pour ça que j'ai besoin d'un moyen d'identifier chaque
instance. J'avais pensé à hashcode mais je ne sais pas si ça ferait
l'affaire

C'est justement l'intérêt de toString() pouvoir distinguer les
instances. Ta classe a bien des propriétés particulières, non?
Utilises-les pour implémenter toString().

--
Gaetan Zoritchak
Gestion de bug en mode ASP sous java
http://eap.bug-sweeper.fr

Gaetan Zoritchak wrote:

Zouplaz wrote:

Black Myst - Black_point_Myst_chez_free_point_fr :

Que souhaites tu faire ?

Distinguer deux instances dans les log. J'ai une classe, dont deux
instances sont créées par un framework. Je log tous les appels mais
comment distinguer une instance d'une autre pour retracer la séquence
d'exécution des méthodes ? C'est pour ça que j'ai besoin d'un moyen
d'identifier chaque instance. J'avais pensé à hashcode mais je ne sais
pas si ça ferait l'affaire

C'est justement l'intérêt de toString() pouvoir distinguer les
instances. Ta classe a bien des propriétés particulières, non?
Utilises-les pour implémenter toString().

En effet, l'utilisation de toString() me semble le plus adapté pour
retourner le TYPE et l'ETAT de tes objets sous une forme textuel.

Quant à distinguer deux IDENTITES, c'est une autre paire de manche...
Aucune mèthode d'instance de la classe Object ne l'assure (même pas
hashcode(), puisqu'elle n'est pas final). Jouer avec un hypothétique
moyen de récuperation d'une adresse n'assurait pas pour autant que cette
adresse ne soit plus jamais utiliser, sauf si tu désactive le garbage
collector (bonne chance ;) ). Bref, je crains qu'il te faille
implémenter toi-même un telle service.

Dans le cas d'une log, la première solution qui me vient à l'espris
serait d'utiliser les mécanisme proposé par ton système de log. Dans le
cas du logger de la J2SE (dans le package java.util.logging), tu peux
facilement minipuler plusieur logger. Ce mécanisme permet de définir
des loggers (nommés) pour chacun de tes sous-systèmes. Or, le type de
sous-système de plus bas niveau n'est autre que l'instance d'objet
elle-même... Ce faisant tu peut lier un logger donnée (et identifiable,
puisque nommé) à un et un seul objet.


Valdo.

Erwan David - erwan@rail.eu.org :

Java vous ne le verrez pas. Pour vos besoins (pouvoir distinguer une
instance d'une autre) le protocole de debug de Java, JPDA, a la notion
d'identificateur d'objet.

Voila, c'est tout à fait ce que je cherche. Où récupérer cette valeur ?
Est-ce le résultat renvoyé par hashCode() qui est censé être unique pour
une session JVM ?

Distinguer deux instances dans les log. J'ai une classe, dont deux
instances sont créées par un framework. Je log tous les appels mais
comment
distinguer une instance d'une autre pour retracer la séquence d'exécution
des méthodes ? C'est pour ça que j'ai besoin d'un moyen d'identifier
chaque
instance. J'avais pensé à hashcode mais je ne sais pas si ça ferait
l'affaire

Utilise directement o1==o2 :
-true si o1 et o2 représentent *le même* objet (c'est à dire la même
instance d'objet)
-false sinon...

ou sinon, dans ta classe, implémente toi-même la méthode equals(Object o),
et effectue des vérifications te permettant de distinguer tes objets (si tu
as besoin de les différencier, ils doivent bien avoir des propriétés
différentes...)

Fais très attention à hashCode : rien (mais alors rien) ne te permet
d'affirmer que deux instances différentes ont des hashcode différents...
La preuve : il te renvoie un "int" : crée "Integer.MAX_VALUE"*2 + 1 objets
différents d'une même classe, et tu en auras forcément deux (différents par
construction...) qui auront le même hashCode...


Fred.

Fais très attention à hashCode : rien (mais alors rien) ne te permet
d'affirmer que deux instances différentes ont des hashcode différents...
La preuve : il te renvoie un "int" : crée "Integer.MAX_VALUE"*2 + 1 objets
différents d'une même classe, et tu en auras forcément deux (différents
par construction...) qui auront le même hashCode...

Ca va être très dur car tu auras une OutOfMemoryException bien avant, à
moins d'être sur un OS 64 bit.

Ce qui n'enlève rien au fond du problème: rien ne garantit que 2 instances
différentes ont des hashCode différents.

Bruno.

Fred.

Zouplaz <pouet@pouet.com> wrote in message news:<Xns960CB7D6B8C88Zoupla@212.27.42.74>...

Bonjour, j'ai besoin
de connaitre l'adresse d'une instance...

Habituellement je me sers de toString() sur pas mal d'objets et par défaut
j'obtiens leur adresse, mais dans certains cas ça ne fonctionne pas
(j'obtiens le nom de la classe par exemple).

Merci

Bonsoir,

La notion d "adresse d'une instance" n'a pas de sens en Java.

Le hashcode n'est pas un id unique, c'est un hashcode. Ce n'est pas
parce qu'il est formaté en hexa qu'il s'agit d'une adresse.

Pour vous en convaincre :

String str1 = new String("toto");
String str2 = new String("toto");

System.out.println(str1.hashCode());
System.out.println(str2.hashCode());

str1 et str2 sont deux objects différents mais ils sont égaux ( au
sens equals() ) donc ils ont le même hashcode.

En fait, je pense que contrairement à ce que vous dites votre besoin
n'est pas de connaitre des adresses d'objet. Ce doit être autre
chose...Définir des identifiants d'objets ou quelque chose de ce
genre. De plus, les identifiants d'objets sont souvent uniques par
type d'objets et pas dans l'absolu.

Bref l'adresse d'un objet n'a de sens que pour celui qui
alloue/désalloue la mémoire or ce mécanisme est gérée par la JVM ( pas
par le développeur ). Donc le développeur n'a jamais besoin de
récupérer cette information dans une utilisation classique de Java ;o)

kpdp

Zouplaz <pouet@pouet.com> wrote in message news:<Xns960CB7D6B8C88Zoupla@212.27.42.74>...

Bref l'adresse d'un objet n'a de sens que pour celui qui
alloue/désalloue la mémoire or ce mécanisme est gérée par la JVM ( pas
par le développeur ). Donc le développeur n'a jamais besoin de
récupérer cette information dans une utilisation classique de Java ;o)

bien vu

peut être qu'en implémentant un simple compteur (synchronized!)
et numéroter chaque objet dans le constructeur...
ca deviens l'object OID

sinon pour éviter le synchronized il y a peut petre moye de passer par
l'environement de thread, mais je me demande si c'est pas pire en fait

sinon une autre solution c'est de ne numéroter l'objet qu'a la demande...
au début il a le numéro inconu (-1 par ex)
et dès qu'on le lui demande, tu demande a une méthode synchonized static
un numéro de série... ca t'évitera d'éfondre ton serveur/appli si tu as
une tempête de création d'objet..

le mieux c'est de faire une classe de base qui fait ca.

pourquoi pas dériver "object"...
sinon si tu ne peut pas change la classe de base, tu peux créer un objet
membre qui porte ton numéro et sers de numéro de série.

Alain - none@none.org :

Zouplaz <pouet@pouet.com> wrote in message
news:<Xns960CB7D6B8C88Zoupla@212.27.42.74>...

Bref l'adresse d'un objet n'a de sens que pour celui qui
alloue/désalloue la mémoire or ce mécanisme est gérée par la JVM (
pas par le développeur ). Donc le développeur n'a jamais besoin de
récupérer cette information dans une utilisation classique de Java
;o)

bien vu

peut être qu'en implémentant un simple compteur (synchronized!)
et numéroter chaque objet dans le constructeur...
ca deviens l'object OID

sinon pour éviter le synchronized il y a peut petre moye de passer
par l'environement de thread, mais je me demande si c'est pas pire en
fait

sinon une autre solution c'est de ne numéroter l'objet qu'a la
demande... au début il a le numéro inconu (-1 par ex)
et dès qu'on le lui demande, tu demande a une méthode synchonized
static un numéro de série... ca t'évitera d'éfondre ton serveur/appli
si tu as une tempête de création d'objet..

le mieux c'est de faire une classe de base qui fait ca.

pourquoi pas dériver "object"...
sinon si tu ne peut pas change la classe de base, tu peux créer un
objet membre qui porte ton numéro et sers de numéro de série.

Bin en voila une idée qui me semble simple et efficace ! Je me prends la
tête pour pas grand chose en fait ;-)

pourquoi pas dériver "object"...
sinon si tu ne peut pas change la classe de base, tu peux créer un objet
membre qui porte ton numéro et sers de numéro de série.

Etant donné qu'il n'est pas possible de faire de la dérivation multiple en
Java, dériver object ne me semble pas une bonne idée : une classe ne pourra
pas dériver à la fois de notre class "object modifiée" et d'une autre classe

--
Vincent

Ca va être très dur car tu auras une OutOfMemoryException bien avant, à
moins d'être sur un OS 64 bit.

Effectivement, enfin ce n'était qu'une illustration.....

Ce qui n'enlève rien au fond du problème: rien ne garantit que 2 instances
différentes ont des hashCode différents.

farpaitement


Fred.