aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Can a.equals(b) be true for a b which does not pass the instanceof test for the class of a? 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 "Can a.equals(b) be true for a b which does not pass the instanceof test for the class of a?" Watch "Can a.equals(b) be true for a b which does not pass the instanceof test for the class of a?" New topic
Author

Can a.equals(b) be true for a b which does not pass the instanceof test for the class of a?

Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
The title asks the whole question. Intuitively it doesn't make much sense for that to happen, but is there any such restriction that I am not aware of? I can't find any in the API. I understand the implications though (if a.equals(b) is true, then a.hashCode() == b.hashCode() must be true, even with B (class of b) being completely unrelated to A (class of A.) This question was prompted by one of the Enthuware quizzes.

Thanks,

Ruben


All code in my posts, unless a source is explicitly mentioned, is my own.
Moojid Hamid
Ranch Hand

Joined: Mar 07, 2009
Posts: 120
In addition to hash code equality, if a.equals(b) then b.equals(a) must also be true, and if a.equals(b) and b.equals(c) then a.equals(c) must also be true.
sudipto shekhar
Ranch Hand

Joined: Apr 02, 2008
Posts: 823

equals() and instanceof operator are they inter-related? I mean two Dog objects may not be equal but may be an instanceof Animal..
Please correct me if I am thinking in the wrong direction


Regards, Sud.
SCJP 5 ScjpFAQ JLS
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
You are both right, but my question was quite different. My question is: Is it legal to code an equals(Object) method for a class A such that it will return true in some cases for objects of class B, where b instanceof A is false? I don't see any restrictions in the API saying that you can't do that, but doing so would be quite impractical, since if a.equals(b) == true, then a.hashCode() == b.hashCode(), but then you are requiring the hashCode() implementations of two different classes to abide by some sort of contract as well. I guess the answer to my question might be "there are no rules against that, but you should never do it."
Leandro Coutinho
Ranch Hand

Joined: Mar 04, 2009
Posts: 417
I don't think that there is a restriction. If you override it, you can do whatever you want (class D equals F that equals z, ...), but it only needs to return a boolean (offcourse =D).

I don't know why you are asking this. I don't see any reason to two objects of different classes be equals.
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
I'm asking this because I saw this question in one of the mocks (like I said earlier.)
Bob Ruth
Ranch Hand

Joined: Jun 04, 2007
Posts: 320
I just took the following at face value:

K & B 5.0, pg 527

First, be sure that the object being tested is of the correct type! It comes in polymorphically as type Object, so you need to do an instanceof test on it. Having two objects of different class types be considered equal is usually not a good idea, but that's a design issue we won't go into here. Besides, you'd have to do the instanceof test just to be sure that you could cast the object argument to the correct type so that you can access it's methods or variables in order to actually do the comparison. Remember, if the object doesn't pass the instanceof test, then you'll get a runtime ClassCastException.

Of course, I know that you can code around just about anything... but this demonstrates to me that there is a reason for adhering to that policy.


------------------------
Bob
SCJP - 86% - June 11, 2009
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Bob Ruth wrote:I just took the following at face value:

K & B 5.0, pg 527

First, be sure that the object being tested is of the correct type! It comes in polymorphically as type Object, so you need to do an instanceof test on it. Having two objects of different class types be considered equal is usually not a good idea, but that's a design issue we won't go into here. Besides, you'd have to do the instanceof test just to be sure that you could cast the object argument to the correct type so that you can access it's methods or variables in order to actually do the comparison. Remember, if the object doesn't pass the instanceof test, then you'll get a runtime ClassCastException.

Of course, I know that you can code around just about anything... but this demonstrates to me that there is a reason for adhering to that policy.

I was aware of that also, Bob. I was wondering why there is no official contract specification in the API regarding this, as it indeed seems it would be a really bad idea to consider two objects of unrelated classes be equal to each other.
Moojid Hamid
Ranch Hand

Joined: Mar 07, 2009
Posts: 120
Having two objects of different class types be considered equal is usually not a good idea, but that's a design issue


I think this pretty much answers the question. Yes it is a bad idea to do it but there are some scenarios where it could be done, e.g. implementing a balanced binary red/black tree, again not the best approach but certainly possible.

The reason I quoted the contract earlier is that if we code the equals method in a.class to allow for equality to b.class we will have to do the same to b.class equal method. This means that the designer intentionally designed the two classes in that manner. As far as API is concerned, if it walks like a duck and talks like a duckā€¦

Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18982
    
  40

Try this...



And of course, an ArrayList is NOT an instanceof LinkedList.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Henry Wong wrote:Try this...



And of course, an ArrayList is NOT an instanceof LinkedList.

Henry

Excellent example, thanks! I hadn't thought of it, but it makes the point very clearly. The List interface specifies expected behavior for equals(), which in this case is that any two instances of implementing classes of List of the same length, and whose corresponding elements are equal, are considered equal.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Can a.equals(b) be true for a b which does not pass the instanceof test for the class of a?