How do you get the "object reference" of an object in java when toString() and hashCode() have been overridden?

Question

I would like to print the "object reference" of an object in Java for debugging purposes. I.e. to make sure that the object is the same (or different) depending on the situation.

The problem is that the class in question inherits from another class, which has overriden both toString() and hashCode() which would usually give me the id.

Example situation: Running a multi-threaded application, where I (during development) want to check if all the threads use the same instance of a resource object or not.

Solution 1

What exactly are you planning on doing with it (what you want to do makes a difference with what you will need to call).

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 Java™ programming language.)

So if you are using hashCode() to find out if it is a unique object in memory that isn't a good way to do it.

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.

Which, for what you are doing, sounds like what you want... but what you want to do might not be safe depending on how the library is implemented.

Solution 2

This is how I solved it:

Integer.toHexString(System.identityHashCode(object));

Solution 3

Double equals == will always check based on object identity, regardless of the objects' implementation of hashCode or equals. Of course - make sure the object references you are comparing are volatile (in a 1.5+ JVM).

If you really must have the original Object toString result (although it's not the best solution for your example use-case), the Commons Lang library has a method ObjectUtils.identityToString(Object) that will do what you want. From the JavaDoc:

public static java.lang.String identityToString(java.lang.Object object)

Gets the toString that would be produced by Object if a class did not override toString itself. null will return null.

 ObjectUtils.identityToString(null)         = null
 ObjectUtils.identityToString("")           = "java.lang.String@1e23"
 ObjectUtils.identityToString(Boolean.TRUE) = "java.lang.Boolean@7fa"

Solution 4

You cannot safely do what you want since the default hashCode() may not return the address, and has been mentioned, multiple objects with the same hashCode are possible. The only way to accomplish what you want, is to actually override the hashCode() method for the objects in question and guarantee that they all provide unique values. Whether this is feasible in your situation is another question.

For the record, I have experienced multiple objects with the same default hashcode in an IBM VM running in a WAS server. We had a defect where objects being put into a remote cache would get overwritten because of this. That was an eye opener for me at that point since I assumed the default hashcode was the objects memory address as well.

Solution 5

we can simply copy the code from tostring of object class to get the reference of string

class Test
{
  public static void main(String args[])
  {
    String a="nikhil";     // it stores in String constant pool
    String s=new String("nikhil");    //with new stores in heap
    System.out.println(Integer.toHexString(System.identityHashCode(a)));
    System.out.println(Integer.toHexString(System.identityHashCode(s)));
  }
}

View more solutions

Comments

[Nicolai]

I am not acting on the value in the code. As pr. my question edit, I only use it for debugging purposes of a certain situation. That is why I feel my answer is reasonable, but I give you a +1 for an insightful reply.

[TofuBeer]

odds are it will always do what you want - but it could break on some VMs.

[Brett]

It'll break (i.e. identityHashCode will not necessarily be unique) on any reasonable VM. identityHashCode is not an I.D.

[Xairoo]

As has been mentioned, there is no guarentee of the hashcode being based on the address. I have seen multiple objects with the same ID occur in the IBM VM inside of WAS.

[Anne Porosoff]

Isn't it true that two objects (references) with the same identity hash are the same object? that's what to OP wants

[TofuBeer]

"This is typically implemented by converting the internal address of the object into an integer" not a gurantee, but the default implementation from Sun. Things like s = "Hello" and t = "Hello" would probably result in s and t having the same identityHashCode as they really are the same object.

[Joachim Sauer]

@TofuBeer: those two would definitely get the same value, as they are the same objects, as defined by the JLS and/or JVM spec (I always remember which one)

[noahlz]

If you are using Java 7, then you should consider using java.util.Objects

[Xairoo]

No, it isn't true. It's very likely, but not guaranteed as the spec does NOT define the algorithm.

[amaidment]

with respect to your comment, what method(s) in java.util.Objects did you have in mind? Objects.toString(o) is equivalent to calling o.toString(), with null checking, which doesn't seem to be relevant to this question.

[noahlz]

@amaidment Ok, yes Object.toString just calls toString on the reference, avoiding NPEs