• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Puzzling question from Mughal and Rasmussen

 
Ranch Hand
Posts: 529
C++ Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
High Plains Drifter
Posts: 7289
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gautam
Please provide some good online resources on hashing.
I dont think i have seen anything like that.
Lakshmi
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Is English more difficult to learn than Java ?
 
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All you are required to know for the certification objective is that the method equals in the Object class is defined thus
<pre>
public boolean equals(Object obj) {
return (this == obj);
}
</pre>

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).]
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.)
--------------------------------------------------------
 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[b]
 
Do Re Mi Fa So La Tiny Ad
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic