This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Java in General and the fly likes Overloading (and NOT overriding) equals() method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Overloading (and NOT overriding) equals() method" Watch "Overloading (and NOT overriding) equals() method" New topic
Author

Overloading (and NOT overriding) equals() method

Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

Hi,

I have been using the equals() method for providing logical comparison among objects of custom made classes by overriding equals() method from class Object. A typical implementation is as follows:



Few days back I came across the fact that unless the 'instanceof' check is true, there is a rare chance (even if there is) that I would declare the two objects logically equal.

Hence, isn't it always advisable to OVERLOAD equals() method instead of OVERRIDING it and providing the check? Have a look at the code below:



I feel like it seems to be a good idea in almost EVERY case.

Any comments on merits/demerits of this approach are welcome.
Stuart Ash
Ranch Hand

Joined: Oct 07, 2005
Posts: 637
Hi Aditya,

The point is that most standard classes doing object comparison use the equals(Object) variant to do the comparison, and your overloaded method does NOT get called by them.

I checked this out with the following code.



and its usage



This gives the result:

in equalsEmp
true
[1, 1]


Which goes to show that thow the two instances were equal as per the employee definition, the set didn't recognize them as so (because it used the equals(Object))

The reason for this is how polymorphism works. Since the set has taken in object references, the equals(Object) method gets called.

Therefore, it is imperative to override equals(Object). The best thing to do perhaps is to simply delegate in the equals(Object) to the equals(Employee) variant method.

I would welcome comments on this.


ASCII silly question, Get a silly ANSI.
Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

Hi Stuart,

Thanks a lot! I got the answer.

When I had this doubt in my mind, I was under an impression that it is the run-time type of parameters that decides which overloaded method to call. Hence, I was assuming equals(Employee) will be called even if the passed reference is of type Object (provided it points to an Employee object).

To my horror, it isn't so. I was a bit surprised (rather, shocked) to see how polymorphism works in this case.

So, I guess it is safe to say that OVERRIDDEN method calls are dynamically dispatched, whereas OVERLOADED method calls are not.

Thanks for the prompt reply,

- Aditya
Lear nable
Greenhorn

Joined: Oct 24, 2005
Posts: 3
Originally posted by Aditya N Jha:
Hi Stuart,
So, I guess it is safe to say that OVERRIDDEN method calls are dynamically dispatched, whereas OVERLOADED method calls are not.
- Aditya


If the runtime has a choice between two methods - method(Object o), and method(SubClassOfObject S), it will always call the more general method i.e. the former, since both methods are applicable.
[ October 27, 2005: Message edited by: Lear nable ]
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Originally posted by Lear nable:


If the runtime has a choice between two methods - method(Object o), and method(SubClassOfObject S), it will always call the more general method i.e. the former, since both methods are applicable.


Sorry to contradict you, but no, this isn't true. The choice between overloaded methods is made by the compiler, and never made at runtime. The above assertion is not even true at compile time: the more specificmethod is chosen then.

I did want to add one thing to this discussion: saying

if (x != null && x instanceof Employee) ...

is always redundant. "null" is never an instance of anything, so "null instanceof Employee" returns false. Therefore, the explicit null check in this code can be removed.


[Jess in Action][AskingGoodQuestions]
 
jQuery in Action, 2nd edition
 
subject: Overloading (and NOT overriding) equals() method
 
Similar Threads
equals() and hashCode() methods
Prolem in EJB
Overriding the equals ( ) method
How to implement hashCode()
Return same hashCode value for CaseInsensitive strings