output reference meaning

[josh]

Hi, in Java we know that pointers are used behind the scenes...but how
?
and if I've a simple code like:

int a[] = new int[3];
System.out.println("a reference is: "a);

what does this output mean?
a reference is: [I@1a8c4e7

Thanks

 

[Robert Klemme]

Hi, in Java we know that pointers are used behind the scenes...but how
?
and if I've a simple code like:

int a[] = new int[3];
System.out.println("a reference is: "a);

This code does not even compile.

what does this output mean?
a reference is: [I@1a8c4e7

You do not get to see memory locations. See
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#toString()

Regards

robert

 

[Patricia Shanahan]

Hi, in Java we know that pointers are used behind the scenes...but how
?
and if I've a simple code like:

int a[] = new int[3];
System.out.println("a reference is: "a);

I think your actual code must have a "+" sign that is missing from the
example. It is better to copy-paste, rather than retype.

Also, saying "a reference is" is a little misleading. You are actually
printing out the result of a.toString(), which for some values of a will
tell you things about the object, not the reference.

what does this output mean?
a reference is: [I@1a8c4e7

"[I@1a8c4e7" is a.toString().

To find out what that means, start with Object's toString:

getClass().getName() + '@' + Integer.toHexString(hashCode())

So "[I" is the name of a's class.

The java.lang.Class API documentation will tell you that the name for an
int array is "[I".

The Object hashCode documentation 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 1a8c4e is certainly a's hashCode, and may be based on its address.

Patricia

 

[josh]

Patricia Shanahan ha scritto:

Hi, in Java we know that pointers are used behind the scenes...but how
?
and if I've a simple code like:

int a[] = new int[3];
System.out.println("a reference is: "a);

I think your actual code must have a "+" sign that is missing from the
example. It is better to copy-paste, rather than retype.

Oh yes, I wrote it in my editor correctly...

So 1a8c4e is certainly a's hashCode, and may be based on its address.

and so is it different from the real address (the reference value of a)
?

 

[Matt Humphrey]

Patricia Shanahan ha scritto:

Hi, in Java we know that pointers are used behind the scenes...but how
?
and if I've a simple code like:

int a[] = new int[3];
System.out.println("a reference is: "a);

I think your actual code must have a "+" sign that is missing from the
example. It is better to copy-paste, rather than retype.

Oh yes, I wrote it in my editor correctly...

So 1a8c4e is certainly a's hashCode, and may be based on its address.

and so is it different from the real address (the reference value of a)
?

Yes, not only is it different from the real address, only the specific JVM
and JIT know for sure how it is related to the real address, if at all AND
the real address may even change over time (ie handle compaction).

When working in Java it is sufficient to think of an object reference as
consistently and uniquely referring to the object, but without making any
claims about where in memory.

Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Chris Uppal]

and so is it different from the real address (the reference value of a)
?

Almost certainly, yes. The Java runtime can /and does/ move the object around
in memory as it sees fit, but the hash code is required to be stable for an
object's lifetime. So the two can't be closely connected.

Another point is that the address of an object (itself not a very well-defined
concept unless you make restrictive assumptions about the implementation
technology) is likely to be a multiple of 8 or 16. If the address were used
"raw" then all hash codes would have zeros in their lower bits -- which
wouldn't be too clever -- so even in an implementation where objects don't
move, the hash code can only be /related to/ the address.


I'll mention two quibbles (to save everyone else the effort ;-):

1) Actually its the identity hash code which can never change, but the two are
the same by default (i.e. unless you have overridden Object.hashCode()).

2) The assertion that the JVM does move objects around is obviously
implementation dependent -- but all the recent JVMs from Sun do.

-- chris