Why Does the Default Object.Tostring() Include the Hashcode

Why does the default Object.toString() include the hashcode?

The object hash code is the only standard identifier that might allow you to tell different arbitrary objects apart in Java. It's not necessarily unique, but equal objects normally have the same hash code.

The default toString() method shows the object class and its hash code so that you can hopefully tell different object instances apart. Since it is also used by default in error messages, this makes quite a bit of sense.

See the description of the hashCode() method for more information.

Why does the default Object.toString() return a hex representation of the hashCode?

Object.hashCode used to be computed based on a memory location where the object is located. Memory locations are almost universally displayed as hexadecimal.

The default return value of toString isn’t so much interested in the hash code but rather in a way to uniquely identify the object for the purpose of debugging, and the hash code serve well for the purpose of identification (in fact, the combination of class name + memory address is truly unique; and while a hash code isn’t guaranteed to be unique, it often comes close).

Object.toString() does not return the hashcode value of the object in java but instead give some string

It represents classname@HashCode_in_Hexadeciaml_form. So, the string which you are seeing is actually the hexadecimal form of the integer hashcode

Why if i try to print an object i get the name of the class followed by a hexadezimal representation?

This is because in Java, System.out.println() applied on an object calls .toString(). The default of the .toString()-method returns the class name followed by @ followed by the hash representation of the object.

Why does the object call toString() affect the output of the object header? I am using the jol package

Your empty class class L uses the default toString() inherited from class Object.

The default toString() invokes hashCode().

And as you have already seen, hashCode() also seems to affect the header of the object.

So, in essence, the problem can be restated as "Why does calling hashCode() alter the header of my object?"

As others have already pointed in the comments, this is happening because in the particular JVM implementation that you are using, the hashCode of an object is computed the first time hashCode() is invoked, and then it is cached in the header, so that subsequent calls to hashCode() can just return the cached value, without having to re-compute it again.

Besides performance, there may be an even more important reason for doing this.

Depending on how the JVM that you are using computes hashcodes, there may be randomness involved in the computations, or there may be an ever-incrementing number seed, so it may be that subsequent attempts to reproduce the hashcode of an object would have no means of generating the exact same value as the first computation. This means that the very first computation must determine what the hashcode value will be forever after.

Doesn't the default Object.toString() append hashCode()?

That's indeed the default implementation of toString(). However, java.lang.Enum, the implicit base class for all enums overrides toString() by returning its name.

why hashCode() gives different output for same object in java?

When you call println() on your object (of type A), it prints getClass().getName() + "@" + Integer.toHexString(hashCode()) (which is the default implementation of toString() in Object class) i.e, it converts hashCode to hexString. If you do the same for your hashCode (when printing), you will get the same value.

If your class overrides toString, then it will be printed.

Java: ToString() prints the same hashcode each time

Try making two instances,

System.out.println(new Point(10, 20));
System.out.println(new Point(10, 20));

And you'll get two distinct hashCodes.

---

Related Topics