File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Puzzling question from Mughal and Rasmussen Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Puzzling question from Mughal and Rasmussen" Watch "Puzzling question from Mughal and Rasmussen" New topic

Puzzling question from Mughal and Rasmussen

Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

In Exam Cram on pg. 299, question 10.2 is very puzzling to me.
Which of these statements are true?
a. If the reference x and y denote 2 different objects, then the expession x.equals(y) is always false.
b. If the reference x and y denote 2 different objects, then the expression (x.hashCode() == y.hashCode() is always false.
(I left out answers c,d,e because they are not relevant to my question)
I would have thought that both a. and b. were correct answers, but apparently not. The authors of the book give this reason, "Neither of the methods hashCode() and equals() is declared final in the Object() class, and it cannot be guaranteed that implementations of these methods will discriminate between all objects."
I cannot find anything in the Java Spec that supports these statements. Can anyone out there in Java land tell me more?
Michael Ernest
High Plains Drifter

Joined: Oct 25, 2000
Posts: 7292

equals() and hashcode() of course both originate in java.lang.Object. I haven't fooled with hashcode() much, but the whole idea of equals() is to override it to re-define equality among two objects of the same type.
Since == covers equality of object references, we use equals() to test equality of actual objects as it suits the class definition. It just so happens that Object defines object equality by the reductio ad absurdum definition, i.e., two objects in memory are deemed equal if they are the same object.
In java.lang.String, two objects (str1,str2) return true on str1.equals(str2) if their String data match; they could still be in different locations in memory.
The reasoning behind the answer you quote seems odd to me; it's not what I would say to defend the correct answer. But a and b are still only true some of the time.
[This message has been edited by Michael Ernest (edited November 04, 2000).]

Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
lakshmi nair
Ranch Hand

Joined: Oct 11, 2000
Posts: 63
Hi Gautam
Please provide some good online resources on hashing.
I dont think i have seen anything like that.
Mary Chaddi

Joined: Nov 01, 2000
Posts: 7

Is English more difficult to learn than Java ?
Sahir Shah
Ranch Hand

Joined: Nov 05, 2000
Posts: 158
All you are required to know for the certification objective is that the method equals in the Object class is defined thus
public boolean equals(Object obj) {
return (this == obj);

which is not really deep comparison (It returns true only if both object references are pointing at the same object) and the fact that those who wish to to implement deep comparison in derived classes ARE expected to override this method. I woudnt worry too much about this aspect of the hashcode method if I were you. The Mughal & Rasmussen book goes a little beyond certification objectives. However if you need information about the hashcode method let me know I shall post it here on this thread.

[This message has been edited by Sahir Shah (edited November 05, 2000).]

Jon Aryan

Joined: Oct 06, 2000
Posts: 22
If the hashCode() method should always return the memory location of the object, wat about the wrapper classes which overrides the hashCode() to return the primitive values ( or some representation of the primitive values) !!! ??
Ok. let me cut n paste the general contract of the hashCode() from the API just 2 remind u ..
Returns a hash code value for the object. This method is supported for the benefit of hashtables such as those provided by java.util.Hashtable.
The general contract of hashCode is:
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.
If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.
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.)
gautam shah
Ranch Hand

Joined: Oct 29, 2000
Posts: 72
I agree. Here's the link:
subject: Puzzling question from Mughal and Rasmussen
It's not a secret anymore!