When I do:
int x[] = new int[2];
System.out.println("...> " + x);
the output value is like this: [I@1b67f74
so that hex number is concerning to the memory address where the object has been allocated?
and [I what does it meaning?
views:
145answers:
4
+7
A:
No, that hex number should not be interpreted as the memory address where the object is located. In fact, it is the hash code of the object. The API documentation of Object.toString() says:
The toString method for class Object returns a string consisting of the name of the class of which the object is an instance, the at-sign character `@', and the unsigned hexadecimal representation of the hash code of the object. In other words, this method returns a string equal to the value of:
getClass().getName() + '@' + Integer.toHexString(hashCode())
The API documentation of java.lang.Object.hashCode() says:
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 JavaTM programming language.)
So for Sun's JVM, if you don't override the hashCode() method, then it's indeed the memory address of the object, but there is no guarantee that this is so, so you shouldn't depend on it.
There is no (real, reliable) way (that works on any JVM) to get the memory address of an object in pure Java; Java does not have pointers, and references are not exactly the same as pointers.
Section 4.3.2 of the Java Virtual Machine Specification explains what the [I means; in this case it means your variable is an array of int.
Jesper
2009-10-08 12:24:28
On Sun's JVM it's derived from the address of the object at the time `hashCode` was first called on it. You'll see odd hash values, for instance, and they will not be addresses. Also the garbage collector moves objects in memory.
Tom Hawtin - tackline
2009-10-08 12:45:56
+1. Also note that on 64-bit VMs, there can't reasonably be a one-to-one mapping between (32-bit) hash codes and (64-bit) object addresses.
gustafc
2009-10-08 12:49:04
No +1 from me. Strictly speaking, the number shown in hex is the object's identityHashcode value. This is only the object's hashcode if the object's class does not override the hashcode method. The identityHashCode may or may not be related to the object's original address. Certainly it won't be related to the object's current address if the GC moves it.
Stephen C
2009-10-08 14:58:52
@Stephen C - added quote from `Object.toString()` documentation. It does not say that it uses the identityHashCode value. For the rest, what you said is exactly what I wrote above...
Jesper
2009-10-08 20:37:51
+1
A:
From: http://stackoverflow.com/questions/1040868/java-syntax-and-meaning-behind-b1ef9157-binary-address
The hex digits are an object ID or hashcode.
RHSeeger
2009-10-08 12:26:25
A:
the [I stands for the class name of an int array. the number of the address in the vm, but since hashCode is typically overridden, it's not wise to use it directly to identify an object. for this, use System.identityHashcode(Object x) which returns the same value in a reliable way.
Omry
2009-10-08 12:30:06
Note that the JVM is at liberty to move objects within memory, and so the System.identityHashcode() in the Sun JVM returns the *initial* address. The actual address may change.
Brian Agnew
2009-10-08 12:43:35
Note that `System.identityHashCode` can give the same value for different objects.
Tom Hawtin - tackline
2009-10-08 12:46:51