toString and hashCode methods usage.

[shiva prasad.]

How toString method and hashCode method can be used in different situations? I want a clear explanation ?

[Piyush Joshi]

what exactly "different situations" mean here? There will be no impact of toString on hashCode and vice-versa.
hashCode contract enforces close relationship restrictions with equals method,but in toString you can always return any String regardless of hashCode.

[shiva prasad.]

shiva prasad. wrote:How toString method and hashCode method can be used in different situations? I want a clear explanation ?

If multiple objects are created for a class what is the default behaviour of this method.
I know it returns string representation of objects but I want to know how the different objects will be differentiated by this method, I want a detailed explanation.
Thank you.

[Joanne Neal]

Object.toString

[Campbell Ritchie]

Your toString() method returns what you want it to return. Look at this code:

Foo f = new Foo(...);
 . . .
System.out.println(f);

What would you want to see on screen in that case? That is what the toString() method must return.

[Piyush Joshi]

Default toString method as defined in Object class returns a string composed of:
ClassName@Hexadecimal Representation of hashCode for that object.
for example:
java.lang.Object@1b67f74
where java.lang.Object is the name of class of this object and 1b67f74 is hexadecimal value of hashCode for this object.

So default behavior of toString depends on the hashCode value of the object.

If you dont override hashCode() then default method returns (practically) unique values for different objects. so same unique values will be reflected in the corresponding toString() methods.

Behavior of default hashCode() method (as defined in Object class) is as follows: (from API)

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified.
This integer need not remain consistent from one execution of an application to another execution of the same application.

[Rohit Mehta]

I strongly feel that its actually the 'equals() & hashcode()' methods usage - you are getting confused with - as these are closely associated, & there are hundreds of pages about (Overriding) these two methods on internet ...

Object class has many methods, among those - equals() & hashcode() are very important from some aspect. lets cover toString first - the least important.

toString() - its a basic method, just provide info about class while doing println(). That' it.

equals() - most important of these three methods. necessary if you want to check if two objects are equal or not (which you always want).

hashcode() - its necessary to override if you are overriding equals - otherwise you will not be able to use the type as key in hash-table based collection implementations.


Kathy has clarified these three in her scjp book in very fine manner. just read those 4-5 pages & you will get a very clear explanation!

[Piyush Joshi]

Rohit Mehta wrote:
toString() - its a very basic method & of not much use as such. just provide info about class while doing println().

It may be a very basic method but it is very useful. Imagine yourself struggling to write a for loop each time you needed to print
all Strings out of an array or a list (It would be painful won't it?). It might be a possibility that users of a widely used class depend on the
format of the String returned by toString() to implement their logic.
For more details See "Item 9: Always override toString" in Effective Java by Joshua Bloch.

[Rohit Mehta]

When I wrote above, I intended to say that its not as important as the rest two methods under discussion here (equals & hashcode) - which are of much higher importance than toString().

Excerpt from "Item 9: Always override toString" ...

While it isn’t as important as obeying the equals and hashCode contracts (Item 7, Item 8), providing a good toString implementation makes your class much more pleasant to use.

Anyway I am editing that. Thanks.