tags:

views:

112

answers:

5

How can I get the reference value of a string object?

If I hava a class like

class T()
{
}
T t = new T();
System.out.println( t); 

print out T@a3455467 that is the reference value inside t

but for string? maybe with method hashCode()??

+2  A: 

print out T@a3455467 that is the reference value inside t

No, that is not the reference value of t, that is simply the value returned by Object.toString for the object referred to by t. (The implementation of the println-method calls the toString method on the given argument.)

If you have say,

String s = "hello world";

then the reference to the string is stored in s. There is no way in Java (as there is in C/C++) to get hold of the "address" of the string (or the value of s).

aioobe
'There is no way in Java (as there is in C/C++) to get hold of the address that s is stored in, or where the string is stored.' which is the reason why java is both a lot less powerful and a lot safer than these languages.
seanizer
...and what do you do desperately need the address of some string for that it's worth the cost in developer time dealing with the issues that arise?
Vuntic
+3  A: 

From the API:

Object.toString(): 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())

So yes, it's simply Integer.toHexString(someString.hashCode()) that you want.


That said, this is not "the reference value of an object". It's just, as it says, the hash code of the object in hexadecimal. Different instances of String which are equals would have the same hashCode(), as per the contract. This would also apply to other types as well.

polygenelubricants
I read that the value inside a reference variable is the value of a pointer memory to which has been applied an hash code function. So that value is not directly the address of memory where is the object pointed but that address converted into its hash code representation. That's not right?
xdevel2000
Not ever - hashCode() can be overridden by any class, which is very common. It should be done if you want to override equals() as well.
Arne Burmeister
@xdevel2000 Object.toString() prints the hex-encoded string of the hashCode. If Object.hashCode() is *not* overridden, then what you will (typically) see is the hex representation of the memory address. But it's still possible that this is not the memory address because the Java specs do not require Object.hashCode() to return the memory address.
Michael Angstadt
A: 

The overloaded String.valueOf( t ) is another way of doing this.

David Soroko
Another way of doing... what? I think we're all confused here what the question is really asking.
polygenelubricants
:-) another way of doing string representation in some sense. Yes you are right, the question is not very clear.
David Soroko
+5  A: 

What you want is the systems identity hash. You can get it by:

int id = System.identityHashCode(t);

The default implementation of Object.toString() is:

public String toString() {
  return getClass().getName() + "@" + Integer.toHexString(hashCode());
}

The default implementation of Object.hashCode() is System.identityHashCode().

But also the systems identity hash code just garantees to be constant for the same instance (not even unique yet). That need not to be the reference value - whatever this will be in the jvm implementation. The real reference value is opaque, not really offered to the public in java. You cannot transform it to a hex address and have a look into memory or something like that.

Arne Burmeister
so the reference value printed by toString() is not the object address transformed with an hash code function?
xdevel2000
@xdevel2000: No. Read the API.
polygenelubricants
ok, I will do that but, can you tell me, then, that value how is calculated??? from what is derived??? it is an hash code of what? very confused!!
xdevel2000
read this: """" hashCode,as defined in the javadocs 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.)
xdevel2000
and this: """ System.identityHashCode does the following: Returns the same hash code for the given object as would be returned by the default method hashCode(), whether or not the given object's class overrides hashCode(). The hash code for the null reference is zero""" so I can resolve the problem of overriding hashCode..
xdevel2000
"But also the systems identity hash code is just garanteed to be unique for identifying the instance." -> wrong. Multiple objects can yield the same identityHashCode. Yes, I know that sounds strange :)
FredOverflow
@xdevel2000 As you have read, Java doesn't specify how Object.hashCode() must be implemented. While Sun's JVM might use the memory address of the object, another JVM could use a completely different technique. There's nothing that says "you *must* use the object's memory address" and so you shouldn't rely on it always returning a memory address. But I wonder how this works on 64-bit systems? The method returns an int, but ints are only 32 bits.
Michael Angstadt
@FredOverflow: Ups, you are right!
Arne Burmeister
@Arne: regarding the bug you link to: I'm pretty sure it won't ever be fixed. Think of a 64 bit JVM. It can hold a lot more than 2^32 objects and as such returning a unique identifier in 32 bit is simply impossible.
Joachim Sauer
@mangst Probably `int hash = (int)((address >>> 32) ^ address)` or something like that.
FredOverflow
+1  A: 

If you mean Reference Value in the sense of Memory Address of an object, this is meaningless in Java. The memory address of an object can change at any time in the age of copying garbage collectors. Furthermore the size of an address depends on JVM host platform/implementation (32/64 bit, possibly even more in future).

Durandal