l' operateur & (fetch address en C) en Java

Le
July
Bonjour,

Je me demande s' il y a moyen pour connaitre, pour une variable v ou une
chemin d' expression genre x.f, son adreese m'emoire ou' elle a 'et'e
h'eberg'e comme dans le langage C, par &v ou &x.f.

Ou bien si on pouvais tricher en faisant sortir ce genre d' informaton
par un programme malin?

Merci bien.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Christian Laborde
Le #20387321
Quel est l'intérêt de faire du C en Java ? Pour quoi faire ?
Salut

July a écrit :
Bonjour,

Je me demande s' il y a moyen pour connaitre, pour une variable v ou une
chemin d' expression genre x.f, son adreese m'emoire ou' elle a 'et'e
h'eberg'e comme dans le langage C, par &v ou &x.f.

Ou bien si on pouvais tricher en faisant sortir ce genre d' informaton
par un programme malin?

Merci bien.



--
Christian Laborde
La Révolution citoyenne, c'est sur : http://c.lab.over-blog.com/
Le forum des électrons libres :
http://electrons-libres.forumactif.fr
Les citoyens qui voient Net : http://www.netoyens.info
True E-mail : remove -no-spam-
Sentier des Vinches
CH 1091 Grandvaux
Suisse
Mayeul
Le #20387471
July wrote:
Je me demande s' il y a moyen pour connaitre, pour une variable v ou une
chemin d' expression genre x.f, son adreese m'emoire ou' elle a 'et'e
h'eberg'e comme dans le langage C, par &v ou &x.f.



Nope.

Ou bien si on pouvais tricher en faisant sortir ce genre d' informaton
par un programme malin?



Dans une JVM, la notion, pour une variable, d'être à une adresse machine
précise au cours de sa vie, est assez vague. Par conséquent, une telle
chose n'est pas à proprement parler possible.
Je suppose toutefois que les développeurs et débuggueurs de JVM ont
accès à une sorte d'équivalent, pour vérifier ce qui se passe.

--
Mayeul
July
Le #20387771
July wrote:
Bonjour,

Je me demande s' il y a moyen pour connaitre, pour une variable v ou une
chemin d' expression genre x.f, son adreese m'emoire ou' elle a 'et'e
h'eberg'e comme dans le langage C, par &v ou &x.f.

Ou bien si on pouvais tricher en faisant sortir ce genre d' informaton
par un programme malin?

Merci bien.



Avec toString() c,a marche. Merci.
Adrien Grand
Le #20388161
Bonsoir,

July a écrit :
Je me demande s' il y a moyen pour connaitre, pour une variable v ou une
chemin d' expression genre x.f, son adreese m'emoire ou' elle a 'et'e
h'eberg'e comme dans le langage C, par &v ou &x.f.



Avec toString() c,a marche. Merci.



En fait, par défaut (ie. dans java.lang.Object), toString() renvoie
${object.getCLass().getName()}@${object.hashCode()} (cf.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#toString())
donc l'information que tu récupères est le hashCode. Mais rien dans la
spécification Java ne te dit que la valeur du hashCode est l'adresse de
l'objet comme le précise la javadoc :

« As much as is reasonably practical, the hashCode method defined by
class Object does return distinct integers for distinct objects. (This
is typically implemented by converting the internal address of the
object into an integer, but this implementation technique is not
required by the Java programming language.) » (cf.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode())

Donc rien ne te dit qu'en passant à une autre implémentation de Java ce
sera toujours l'adresse de l'objet qui te sera renvoyée.

--
Adrien
Samuel Devulder
Le #20396221
July a écrit :
Bonjour,

Je me demande s' il y a moyen pour connaitre, pour une variable v ou une
chemin d' expression genre x.f, son adreese m'emoire ou' elle a 'et'e
h'eberg'e comme dans le langage C, par &v ou &x.f.



L'adresse mémoire en java pur n'a pas de sens. Les objets sont tous
alloués dans le tas et les variables sont des références sur ces objets,
donc déjà des adresses mémoire. Pour les objets primitifs (int, float),
l'adresse mémoire a encore moins de sens. Seul leur valeur importe.

Maintenant si tu veux l'interfacer avec un truc qui a besoin d'une
addresse mémoire, utilises l'API jni pour acceder aux champs des objets.
Attention, je crois qu'on y a pas accès directement, mais via des
méthode d'accesseur: get/set. Le plus proche de la notion d'adresse
mémoire est d'utiliser coté java un tableau d'objet primitif et du coté
C (jni) de récupèrer l'adresse du 1er element du tableau.

Par contre si tu veux parler de l'adresse mémoire pour "inspecter" les
variables, il y a l'API du debugger qui te permet de faire des trucs
assez poussé.


Ou bien si on pouvais tricher en faisant sortir ce genre d' informaton
par un programme malin?



Si tu utilises je JNI, fais bien attention à punaiser ton objet en
mémoire le temps de son usage en utilisant correctement l'API car la JVM
peut parfaitement reloger les objets pour éviter la fragmentation mémoire.

Bref: tout cela pour dire que l'adresse mémoire d'un objet et pire d'une
variable (sur la pile) n'a pas trop de sens dans le contexte java où
tout est référence (hormis les types primitifs).

sam.
Patrick
Le #20398271
Le 20/10/2009 15:42, July a écrit :

Je me demande s' il y a moyen pour connaitre, pour une variable v ou une
chemin d' expression genre x.f, son adreese m'emoire ou' elle a 'et'e
h'eberg'e comme dans le langage C, par &v ou &x.f.




System.identityHashCode (Object)

(Mais rien ne garantit que c'est vraiment une adresse mémoire.)
TestMan
Le #20398581
On 20/10/2009 19:13, Adrien Grand wrote:
Bonsoir,

July a écrit :
Je me demande s' il y a moyen pour connaitre, pour une variable v ou une
chemin d' expression genre x.f, son adreese m'emoire ou' elle a 'et'e
h'eberg'e comme dans le langage C, par&v ou&x.f.



Avec toString() c,a marche. Merci.



En fait, par défaut (ie. dans java.lang.Object), toString() renvoie
${object.getCLass().getName()}@${object.hashCode()} (cf.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#toString())
donc l'information que tu récupères est le hashCode. Mais rien dans la
spécification Java ne te dit que la valeur du hashCode est l'adresse de
l'objet comme le précise la javadoc :

« As much as is reasonably practical, the hashCode method defined by
class Object does return distinct integers for distinct objects. (This
is typically implemented by converting the internal address of the
object into an integer, but this implementation technique is not
required by the Java programming language.) » (cf.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode())

Donc rien ne te dit qu'en passant à une autre implémentation de Java ce
sera toujours l'adresse de l'objet qui te sera renvoyée.




+1

Je rajouterais par rapport à la question initiale qu'il existe bien une
façon de connaitre le positionement mémoire de ces éléments via JNI.

De la même façon que l'on peut énumerer tous les objets d'une même
classe par exemple...

Mais sincèrement, outre le fait que celà nécessite du code JNI "sympa"
ce ne doit jamais être utilisé dans un problamme traditionel.

A+
TM
Wykaaa
Le #20399771
Patrick a écrit :
Le 20/10/2009 15:42, July a écrit :
Je me demande s' il y a moyen pour connaitre, pour une variable v ou une
chemin d' expression genre x.f, son adreese m'emoire ou' elle a 'et'e
h'eberg'e comme dans le langage C, par &v ou &x.f.




System.identityHashCode (Object)

(Mais rien ne garantit que c'est vraiment une adresse mémoire.)


On peut même garantir que ça ne retourne pas une adresse mémoire puisque
ça retourne un hashcode...

Confondre adresse mémoire et hashcode c'est vraiment...confondant
puisque les adresses mémoires peuvent être "hashcodées" et qu'une clé de
hashcode n'a rien à voir avec une adresse mémoire !

Pour revenir à la question du posteur d'origine, sa question n'a pas de
sens en Java et on se demande même quelle est l'utilité de connaître
l'adresse mémoire d'un objet dans un programme.
D'ailleurs, sur les machines actuelles, avec la pagination mémoire et
plein d'autres dispositifs concernant la gestion mémoire (comme le
ramasse-miette), il est impossible de connaître la "vraie" adresse
mémoire. D'ailleurs on s'en contrefout !

Il y a même des ordinateurs dans lesquels, lorsqu'un "banc mémoire" est
en panne, il est "oublié" et les adresses mémoires situées de part et
d'autre de cette zone mémoire en panne sont concaténées. Dans de telles
machines, l'adresse "réelle" n'a, en vérité, aucune réalité...
Publicité
Poster une réponse
Anonyme