wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes Overriding equals() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Overriding equals()" Watch "Overriding equals()" New topic
Author

Overriding equals()

Vikas Kapoor
Ranch Hand

Joined: Aug 16, 2007
Posts: 1374
I am referring K&B study guide for Java 6.
Below is one of the ways to override equals() method that they have suggested.

Can I change it to


What are the implications?
Thomas Young
Greenhorn

Joined: Jul 17, 2008
Posts: 29
Hi,
You can take a look at the following thread for a discussion on
the Difference between == and .equals Which may assist you.

Regards,
TY.
Vikas Kapoor
Ranch Hand

Joined: Aug 16, 2007
Posts: 1374
Thomas, Thanks for your reply.

I am aware about various differences between == (Operator) and equals (method)in context of Object class.

But here I am comparing two String Objects (String name) and for String class == and equals work same way.

I want to know that if I use equals instead of == then is it fine?
Any comments on that?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2991
    
    9
[Vishal]: But here I am comparing two String Objects (String name) and for String class == and equals work same way.

No, that's not true. They don't.

Possibly you read something about String literals? Or Strings returned by the intern() method? If both Strings involved in a comparison either came from String literals or were returned by the intern() method, then == will yield the same result as equals(). But if either String cam from any other source (like new String() or readLine() or split() or the many other ways that Strings can appear in a program) then == and .equals() are NOT equivalent.

[Vishal]: want to know that if I use equals instead of == then is it fine?
Any comments on that?


Well, they are NOT equivalent. If anything, using .equals() seems to make a lot more sense. I don't have a copy of the book you're getting this from, so I don't know if this is a mistake in the book, or if there was additional information in the book which you've overlooked. But in general, using == in this method seems like a bad idea, and using .equals() seems like a good one.
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874

But here I am comparing two String Objects (String name) and for String class == and equals work same way.

No. It depends on mutability and immutability of a String.


I want to know that if I use equals instead of == then is it fine?
Any comments on that?

You will definitely get the same result but it might not be fine. It would be a performance hit. So, I would say, use '==' wherever possible and appropriate.
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by Mike Simmons:
But in general, using == in this method seems like a bad idea, and using .equals() seems like a good one.


No Simmons, its not that. I am pretty sure he missed something there. The idea behind using '==' operator early on, is to avoid further computation, which is bootless in case of same references.
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4523
    
    5

Originally posted by Adeel Ansari:
No. It depends on mutability and immutability of a String.

String is immutable, so that doesn't make any sense at all.

Originally posted by Adeel Ansari:
You will definitely get the same result but it might not be fine. It would be a performance hit. So, I would say, use '==' wherever possible and appropriate.

Micro optimization, significant only over millions of operations.

In general, using == where the philosophy of the program demands testing content and not identity equality leads to brittle code that can easily be broken by changes elsewhere. The purpose of the test should always be the primary reason for electing to use == or .equals().


luck, db
There are no new questions, but there may be new answers.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2991
    
    9
[AA]: The idea behind using '==' operator early on, is to avoid further computation, which is bootless in case of same references.

That's a possible application of using == rather than equals(), yes. But avoiding computation is only good if you still get the correct answer, and from what we've seen of the code so far, that's unlikely to happen using == here.

There are ways that this code could be made to be correct, if the Shape.name field is initialized a certain way, e.g.

However I kind of doubt K&B would put that sort of thing into their SCJP book, as it's relatively obscure. I think it's more likely that either (a) the original poster overlooked a discussion in the text about why using == here is a bad idea, or (b) this is an error in K&B. Hard to say unless someone who actually has K&B provides some further details here.
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by Darryl Burke:
String is immutable, so that doesn't make any sense at all.


What I mean was,



I don't know how to say it in plain english, I use the term mutable/immutable may be wrongly.
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by Mike Simmons:
...from what we've seen of the code so far, that's unlikely to happen using '==' here.


I agree.
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by Darryl Burke:
In general, using == where the philosophy of the program demands testing content and not identity equality leads to brittle code that can easily be broken by changes elsewhere. The purpose of the test should always be the primary reason for electing to use == or .equals().


Checking for same reference is a good practice when over-riding equals() method. After that, of course, there are other things to check and in a proper way to grant equality/non-equality.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37958
    
  22
Most likely the book intends you to find the error in that implementation of equals(). There is discussion of equals() in Joshua Bloch's Effective Java and from Angelika Langer.

By the way, the original you quoted has a stylistic error in; it ought to readYou ought not to write if (...) return true else return false;
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Overriding equals()
 
Similar Threads
Incorrect equals() implementation...
Confusion on equals() method
NullPointerException when removing objects, for which equals() is overriden, from JComboBox
okay what am i doing wrong?
override equals