output reference meaning

Thread view:

josh - 19 Oct 2006 14:35 GMT

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

Reply to this Message

Robert Klemme - 19 Oct 2006 14:43 GMT

> 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

Reply to this Message

Patricia Shanahan - 19 Oct 2006 15:13 GMT

> 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

Reply to this Message

josh - 19 Oct 2006 15:56 GMT

Patricia Shanahan ha scritto:

> > Hi, in Java we know that pointers are used behind the scenes...but how
> > ?
[quoted text clipped - 5 lines]
> 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)
?

Reply to this Message

Matt Humphrey - 19 Oct 2006 16:29 GMT

> Patricia Shanahan ha scritto:
>
[quoted text clipped - 14 lines]
> 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 matth@ivizNOSPAM.com http://www.iviz.com/

Reply to this Message

Chris Uppal - 19 Oct 2006 16:31 GMT

> > 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)
> ?

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

Reply to this Message

output reference meaning

Free Magazines