Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20431 > unrolled thread

Need clarification on Object.equals.

Back to article view | Back to comp.lang.java.programmer

Contents

  Need clarification on Object.equals. "plewto@gmail.com" <plewto@gmail.com> - 2012-12-18 00:13 -0800
    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-18 10:39 +0000
      Re: Need clarification on Object.equals. Roedy Green <see_website@mindprod.com.invalid> - 2012-12-18 04:48 -0800
        Re: Need clarification on Object.equals. Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-18 10:56 -0800
          Re: Need clarification on Object.equals. FredK <fred.l.kleinschmidt@gmail.com> - 2012-12-19 08:13 -0800
            Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 11:22 -0500
              Re: Need clarification on Object.equals. Lars Enderin <lars.enderin@telia.com> - 2012-12-19 17:43 +0100
                Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 12:06 -0500
                  Re: Need clarification on Object.equals. Patricia Shanahan <pats@acm.org> - 2012-12-19 09:39 -0800
                    Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 13:24 -0500
              Re: Need clarification on Object.equals. FredK <fred.l.kleinschmidt@gmail.com> - 2012-12-19 11:23 -0800
            Re: Need clarification on Object.equals. Patricia Shanahan <pats@acm.org> - 2012-12-19 08:25 -0800
      Re: Need clarification on Object.equals. plewto@gmail.com - 2012-12-18 10:56 -0800
        Re: Need clarification on Object.equals. Jim Janney <jjanney@shell.xmission.com> - 2012-12-18 14:24 -0700
          Re: Need clarification on Object.equals. Patricia Shanahan <pats@acm.org> - 2012-12-18 13:52 -0800
    Re: Need clarification on Object.equals. markspace <-@.> - 2012-12-18 10:24 -0800
      Re: Need clarification on Object.equals. plewto@gmail.com - 2012-12-18 10:48 -0800
        Re: Need clarification on Object.equals. David Lamb <dalamb@cs.queensu.ca> - 2012-12-18 14:01 -0500
          Re: Need clarification on Object.equals. plewto@gmail.com - 2012-12-18 12:14 -0800
            Re: Need clarification on Object.equals. plewto@gmail.com - 2012-12-18 12:17 -0800
              Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 22:16 -0500
                Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 10:20 +0000
                  Re: Need clarification on Object.equals. Patricia Shanahan <pats@acm.org> - 2012-12-19 03:22 -0800
                    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 12:06 +0000
                    Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 09:07 -0500
                      Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 09:09 -0500
                        Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 14:36 +0000
                          Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 09:42 -0500
                            Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 15:05 +0000
                              Re: Need clarification on Object.equals. Lars Enderin <lars.enderin@telia.com> - 2012-12-19 16:15 +0100
                                Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 15:47 +0000
                                  Re: Need clarification on Object.equals. Lars Enderin <lars.enderin@telia.com> - 2012-12-19 16:57 +0100
                                    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 16:51 +0000
                                      Re: Need clarification on Object.equals. Lars Enderin <lars.enderin@telia.com> - 2012-12-19 18:12 +0100
                                        Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 17:27 +0000
                                          Re: Need clarification on Object.equals. Gene Wirchenko <genew@telus.net> - 2012-12-19 11:40 -0800
                              Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 10:17 -0500
                                Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 15:40 +0000
                                  Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 10:50 -0500
                                  Re: Need clarification on Object.equals. Lars Enderin <lars.enderin@telia.com> - 2012-12-19 17:01 +0100
                                  Re: Need clarification on Object.equals. Gene Wirchenko <genew@telus.net> - 2012-12-19 10:22 -0800
                                    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 18:49 +0000
                                      Re: Need clarification on Object.equals. Gene Wirchenko <genew@telus.net> - 2012-12-19 11:41 -0800
                                      Re: Need clarification on Object.equals. Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-19 17:05 -0800
                                        Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-20 08:34 +0000
                                          Re: Need clarification on Object.equals. Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-20 07:27 -0800
                                          Re: Need clarification on Object.equals. Gene Wirchenko <genew@telus.net> - 2012-12-20 09:04 -0800
                                            Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-20 18:10 +0000
                                              Re: Need clarification on Object.equals. Lew <lewbloch@gmail.com> - 2012-12-20 11:08 -0800
                                                Re: Need clarification on Object.equals. Peter Dunihơ <Np0eStPeAdM@NnOwSlPiAnMk.com> - 2012-12-21 07:50 +0000
                                                  Re: Need clarification on Object.equals. Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-21 07:30 -0800
                                                    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-21 17:09 +0000
                                                      Re: Need clarification on Object.equals. Leŵ <lewbl0ch@gmail.com> - 2012-12-23 00:54 +0000
                                                    Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-21 12:23 -0500
                                                      Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-21 17:38 +0000
                                                    Re: Need clarification on Object.equals. Arne Vajhoj <arne@vajhoj.dk> - 2012-12-23 00:50 +0000
                                                Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-21 08:39 +0000
                                              Re: Need clarification on Object.equals. Gene Wirchenko <genew@telus.net> - 2012-12-20 13:39 -0800
                                                Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-21 08:34 +0000
                              Re: Need clarification on Object.equals. Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-19 09:22 -0600
                                Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 15:35 +0000
                                Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 10:56 -0500
                            Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 17:08 +0000
                          Re: Need clarification on Object.equals. Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-19 08:58 -0600
                            Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 15:32 +0000
                              Re: Need clarification on Object.equals. Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-19 11:08 -0600
                                Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 17:32 +0000
                                  Re: Need clarification on Object.equals. Lars Enderin <lars.enderin@telia.com> - 2012-12-19 18:41 +0100
                                    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 17:58 +0000
                                      Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 18:12 +0000
                                      Re: Need clarification on Object.equals. Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-19 12:29 -0600
                                  Re: Need clarification on Object.equals. Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-19 12:00 -0600
                                    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 18:06 +0000
                                      Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 13:13 -0500
                          Re: Need clarification on Object.equals. Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-19 07:48 -0800
                            Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 16:48 +0000
                              Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 12:09 -0500
                                Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 17:50 +0000
                                  Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 13:14 -0500
                                    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 18:59 +0000
                                  Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 13:16 -0500
                                    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 19:05 +0000
                                      Re: Need clarification on Object.equals. Gene Wirchenko <genew@telus.net> - 2012-12-19 11:45 -0800
                                        Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 20:00 +0000
                              Re: Need clarification on Object.equals. Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-19 17:15 -0800
                                Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-20 09:22 +0000
                                  Re: Need clarification on Object.equals. Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-20 07:36 -0800
                          Re: Need clarification on Object.equals. Gene Wirchenko <genew@telus.net> - 2012-12-19 10:19 -0800
                            Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-19 19:16 +0000
                              Re: Need clarification on Object.equals. Gene Wirchenko <genew@telus.net> - 2012-12-19 11:48 -0800
                              Re: Need clarification on Object.equals. Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-19 14:12 -0600
                  Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 09:04 -0500
                  Re: Need clarification on Object.equals. Lew <lewbloch@gmail.com> - 2012-12-19 13:40 -0800
                    Re: Need clarification on Object.equals. lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-20 09:30 +0000
            Re: Need clarification on Object.equals. Lew <lewbloch@gmail.com> - 2012-12-18 12:52 -0800
            Re: Need clarification on Object.equals. Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-19 09:27 -0600
              Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 10:44 -0500
        Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 22:11 -0500
    Re: Need clarification on Object.equals. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 22:10 -0500

Page 1 of 5  [1] 2 3 4 5  Next page →

#20431 — Need clarification on Object.equals.

In the following code Node is an abstract class and both Gate and
Monitor are extensions of Node. a and b are distinct objects yet
a.equals(b) is returning true.

public class Foo {
    public static void main(String[] argv){
	Node a = new Gate();
	Monitor b = new Monitor();
	System.out.println(a.equals(b)); // --> prints 'true'
    }
}

The underlying production code is a bit complex to include here. My
understanding is that equals is true if, and only if, a and b are
exactly the same object. Here they are not even the same class.


I did do a test stripped down to the bare essence:

public class Foo {
    public static void main(String[] argv){
	Foo a = new Bar();
	Foo b = new Bar();
	System.out.println(a.equals(b)); // --> prints 'false'
    }
}
class Bar extends Foo {}

In this case the results are as I expected, a.equals(b) --> false

What could be going on here?

java version 1.7.0_06  on 64-bit Fedora 17

[toc] | [next] | [standalone]

#20436

On 18/12/12 08:13, plewto@gmail.com wrote:
> In the following code Node is an abstract class and both Gate and
> Monitor are extensions of Node. a and b are distinct objects yet
> a.equals(b) is returning true.
>
> public class Foo {
>      public static void main(String[] argv){
> 	Node a = new Gate();
> 	Monitor b = new Monitor();
> 	System.out.println(a.equals(b)); // -->  prints 'true'
>      }
> }

According to the documentation the contract for equals on instances of 
class Object is as follows

"The equals method for class Object implements the most discriminating 
possible equivalence relation on objects; that is, for any non-null 
reference values x and y, this method returns true if and only if x and 
y refer to the same object (x == y has the value true)."

This is obviously the not the case in your example above.
Does the class Node or any of it's superclasses override the equals method ?

The following code returns false as expected

public abstract class Foo {

    public static void main(String args[]){
       Foo bar = new Bar();
       Baz baz = new Baz();
       System.out.println(bar.equals(baz));
    }
}

class Bar extends Foo{}

class Baz extends Foo{}

...

However, add the following method to the class Foo

public boolean equals(Object obj){
    return true;
}

and re-run the code and we get true.

Has someone been messing with equals ?

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#20437

On Tue, 18 Dec 2012 10:39:27 +0000, lipska the kat
<lipskathekat@yahoo.co.uk> wrote, quoted or indirectly quoted someone
who said :

>> 	Node a = new Gate();
>> 	Monitor b = new Monitor();
>> 	System.out.println(a.equals(b)); // -->  prints 'true'

Gate or one of its superclasses is implementing equals.  
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#20466

On Tue, 18 Dec 2012 04:48:16 -0800, Roedy Green wrote:

> On Tue, 18 Dec 2012 10:39:27 +0000, lipska the kat
> <lipskathekat@yahoo.co.uk> wrote, quoted or indirectly quoted someone
> who said :
> 
>>> 	Node a = new Gate();
>>> 	Monitor b = new Monitor();
>>> 	System.out.println(a.equals(b)); // -->  prints 'true'
> 
> Gate or one of its superclasses is implementing equals.

And doing it incorrectly, I'd say.

[toc] | [prev] | [next] | [standalone]

#20545

On Tuesday, December 18, 2012 10:56:19 AM UTC-8, Peter Duniho wrote:
> On Tue, 18 Dec 2012 04:48:16 -0800, Roedy Green wrote: > On Tue, 18 Dec 2012 10:39:27 +0000, lipska the kat > <lipskathekat@yahoo.co.uk> wrote, quoted or indirectly quoted someone > who said : > >>> Node a = new Gate(); >>> Monitor b = new Monitor(); >>> System.out.println(a.equals(b)); // --> prints 'true' > > Gate or one of its superclasses is implementing equals. And doing it incorrectly, I'd say.

Why would you think it was done incorrectly?
For most classes, a.equals(b) is not the same as a==b.
Think about string:
string a = "abc");
string b = new string(a);
Clearly a==b is false, but a.equals(b) is true.

Usually the equals() method returns true if the internal state of both objects is the same. 

[toc] | [prev] | [next] | [standalone]

#20546

On 12/19/2012 11:13 AM, FredK wrote:
> On Tuesday, December 18, 2012 10:56:19 AM UTC-8, Peter Duniho wrote:
>> On Tue, 18 Dec 2012 04:48:16 -0800, Roedy Green wrote:
>>>> Node a = new Gate();
>>>> Monitor b = new Monitor();
>>>> System.out.println(a.equals(b)); // --> prints 'true'
>>> Gate or one of its superclasses is implementing equals.
>>And doing it incorrectly, I'd say.
>
> Why would you think it was done incorrectly?
> For most classes, a.equals(b) is not the same as a==b.
> Think about string:
> string a = "abc");
> string b = new string(a);
> Clearly a==b is false, but a.equals(b) is true.
>
> Usually the equals() method returns true if the internal state of both objects is the same.

It is rather unusual to have objects of different classes considered
equals.

Your example is different.

Arne

[toc] | [prev] | [next] | [standalone]

#20548

2012-12-19 17:22, Arne Vajhøj skrev:
> On 12/19/2012 11:13 AM, FredK wrote:
>> On Tuesday, December 18, 2012 10:56:19 AM UTC-8, Peter Duniho wrote:
>>> On Tue, 18 Dec 2012 04:48:16 -0800, Roedy Green wrote:
>>>>> Node a = new Gate();
>>>>> Monitor b = new Monitor();
>>>>> System.out.println(a.equals(b)); // --> prints 'true'
>>>> Gate or one of its superclasses is implementing equals.
>>> And doing it incorrectly, I'd say.
>>
>> Why would you think it was done incorrectly?
>> For most classes, a.equals(b) is not the same as a==b.
>> Think about string:
>> string a = "abc");
>> string b = new string(a);
>> Clearly a==b is false, but a.equals(b) is true.
>>
>> Usually the equals() method returns true if the internal state of both
>> objects is the same.
> 
> It is rather unusual to have objects of different classes considered
> equals.
> 
> Your example is different.

Both Gate and Monitor were extensions of AbstractSet, and empty, which
eventually led to Set#containsAll, and thus equals, returning true.

-- 
Lars Enderin

[toc] | [prev] | [next] | [standalone]

#20551

On 12/19/2012 11:43 AM, Lars Enderin wrote:
> 2012-12-19 17:22, Arne Vajhøj skrev:
>> On 12/19/2012 11:13 AM, FredK wrote:
>>> On Tuesday, December 18, 2012 10:56:19 AM UTC-8, Peter Duniho wrote:
>>>> On Tue, 18 Dec 2012 04:48:16 -0800, Roedy Green wrote:
>>>>>> Node a = new Gate();
>>>>>> Monitor b = new Monitor();
>>>>>> System.out.println(a.equals(b)); // --> prints 'true'
>>>>> Gate or one of its superclasses is implementing equals.
>>>> And doing it incorrectly, I'd say.
>>>
>>> Why would you think it was done incorrectly?
>>> For most classes, a.equals(b) is not the same as a==b.
>>> Think about string:
>>> string a = "abc");
>>> string b = new string(a);
>>> Clearly a==b is false, but a.equals(b) is true.
>>>
>>> Usually the equals() method returns true if the internal state of both
>>> objects is the same.
>>
>> It is rather unusual to have objects of different classes considered
>> equals.
>>
>> Your example is different.
>
> Both Gate and Monitor were extensions of AbstractSet, and empty, which
> eventually led to Set#containsAll, and thus equals, returning true.

Yes. We know that now. And the problem was solved by not
extending that.

But if the class should continue to extend from
that it should probably have overridden equals again
with an implementation that did use instanceof to test
for type (it could have called super.equals after that
if appropriate).

Arne

[toc] | [prev] | [next] | [standalone]

#20558

On 12/19/2012 9:06 AM, Arne Vajhøj wrote:
> On 12/19/2012 11:43 AM, Lars Enderin wrote:
>> 2012-12-19 17:22, Arne Vajhøj skrev:
>>> On 12/19/2012 11:13 AM, FredK wrote:
>>>> On Tuesday, December 18, 2012 10:56:19 AM UTC-8, Peter Duniho wrote:
>>>>> On Tue, 18 Dec 2012 04:48:16 -0800, Roedy Green wrote:
>>>>>>> Node a = new Gate();
>>>>>>> Monitor b = new Monitor();
>>>>>>> System.out.println(a.equals(b)); // --> prints 'true'
>>>>>> Gate or one of its superclasses is implementing equals.
>>>>> And doing it incorrectly, I'd say.
>>>>
>>>> Why would you think it was done incorrectly?
>>>> For most classes, a.equals(b) is not the same as a==b.
>>>> Think about string:
>>>> string a = "abc");
>>>> string b = new string(a);
>>>> Clearly a==b is false, but a.equals(b) is true.
>>>>
>>>> Usually the equals() method returns true if the internal state of both
>>>> objects is the same.
>>>
>>> It is rather unusual to have objects of different classes considered
>>> equals.
>>>
>>> Your example is different.
>>
>> Both Gate and Monitor were extensions of AbstractSet, and empty, which
>> eventually led to Set#containsAll, and thus equals, returning true.
>
> Yes. We know that now. And the problem was solved by not
> extending that.
>
> But if the class should continue to extend from
> that it should probably have overridden equals again
> with an implementation that did use instanceof to test
> for type (it could have called super.equals after that
> if appropriate).

AbstractSet implements Set, so all its subclasses also implement Set.

That means they are bound by the Set contract for .equals, which treats
all classes that implement Set the same way. There might be a
performance advantage to overriding AbstractSet's .equals in some cases,
but its result would have to be preserved.

The right solution is, of course, the action the OP is already taking -
don't extend AbstractSet unless you really are implementing a Set, and
intend to follow the Set contract.

Patricia

[toc] | [prev] | [next] | [standalone]

#20576

On 12/19/2012 12:39 PM, Patricia Shanahan wrote:
> On 12/19/2012 9:06 AM, Arne Vajhøj wrote:
>> On 12/19/2012 11:43 AM, Lars Enderin wrote:
>>> 2012-12-19 17:22, Arne Vajhøj skrev:
>>>> On 12/19/2012 11:13 AM, FredK wrote:
>>>>> On Tuesday, December 18, 2012 10:56:19 AM UTC-8, Peter Duniho wrote:
>>>>>> On Tue, 18 Dec 2012 04:48:16 -0800, Roedy Green wrote:
>>>>>>>> Node a = new Gate();
>>>>>>>> Monitor b = new Monitor();
>>>>>>>> System.out.println(a.equals(b)); // --> prints 'true'
>>>>>>> Gate or one of its superclasses is implementing equals.
>>>>>> And doing it incorrectly, I'd say.
>>>>>
>>>>> Why would you think it was done incorrectly?
>>>>> For most classes, a.equals(b) is not the same as a==b.
>>>>> Think about string:
>>>>> string a = "abc");
>>>>> string b = new string(a);
>>>>> Clearly a==b is false, but a.equals(b) is true.
>>>>>
>>>>> Usually the equals() method returns true if the internal state of both
>>>>> objects is the same.
>>>>
>>>> It is rather unusual to have objects of different classes considered
>>>> equals.
>>>>
>>>> Your example is different.
>>>
>>> Both Gate and Monitor were extensions of AbstractSet, and empty, which
>>> eventually led to Set#containsAll, and thus equals, returning true.
>>
>> Yes. We know that now. And the problem was solved by not
>> extending that.
>>
>> But if the class should continue to extend from
>> that it should probably have overridden equals again
>> with an implementation that did use instanceof to test
>> for type (it could have called super.equals after that
>> if appropriate).
>
> AbstractSet implements Set, so all its subclasses also implement Set.
>
> That means they are bound by the Set contract for .equals, which treats
> all classes that implement Set the same way. There might be a
> performance advantage to overriding AbstractSet's .equals in some cases,
> but its result would have to be preserved.

If the Set interface specify the behavior of equals, then testing for
type is not valid.

Testing for type may only make sense on domain classes and not
for container classes at all.

> The right solution is, of course, the action the OP is already taking -
> don't extend AbstractSet unless you really are implementing a Set, and
> intend to follow the Set contract.

Yes.

Arne

[toc] | [prev] | [next] | [standalone]

#20586

On Wednesday, December 19, 2012 8:22:28 AM UTC-8, Arne Vajhøj wrote:
> On 12/19/2012 11:13 AM, FredK wrote: > On Tuesday, December 18, 2012 10:56:19 AM UTC-8, Peter Duniho wrote: >> On Tue, 18 Dec 2012 04:48:16 -0800, Roedy Green wrote: >>>> Node a = new Gate(); >>>> Monitor b = new Monitor(); >>>> System.out.println(a.equals(b)); // --> prints 'true' >>> Gate or one of its superclasses is implementing equals. >>And doing it incorrectly, I'd say. > > Why would you think it was done incorrectly? > For most classes, a.equals(b) is not the same as a==b. > Think about string: > string a = "abc"); > string b = new string(a); > Clearly a==b is false, but a.equals(b) is true. > > Usually the equals() method returns true if the internal state of both objects is the same. It is rather unusual to have objects of different classes considered equals. Your example is different. Arne

Which points out that the real issue is that you must define what you want equals() to mean. There may well be situations where two objects of different classes could be considered to be "equal" ( Consider a Square with side=2, and a (immutable) Rectangle with width=2 and length=2 )

[toc] | [prev] | [next] | [standalone]

#20547

On 12/19/2012 8:13 AM, FredK wrote:
> On Tuesday, December 18, 2012 10:56:19 AM UTC-8, Peter Duniho wrote:
>> On Tue, 18 Dec 2012 04:48:16 -0800, Roedy Green wrote: > On Tue, 18 Dec 2012 10:39:27 +0000, lipska the kat > <lipskathekat@yahoo.co.uk> wrote, quoted or indirectly quoted someone > who said : > >>> Node a = new Gate(); >>> Monitor b = new Monitor(); >>> System.out.println(a.equals(b)); // --> prints 'true' > > Gate or one of its superclasses is implementing equals. And doing it incorrectly, I'd say.
>
> Why would you think it was done incorrectly?
> For most classes, a.equals(b) is not the same as a==b.
> Think about string:
> string a = "abc");
> string b = new string(a);
> Clearly a==b is false, but a.equals(b) is true.
>
> Usually the equals() method returns true if the internal state of both objects is the same.
>

I think "inappropriately" might have been a better word than
"incorrectly". The inherited .equals method was a fine .equals method
for a Set. Indeed, it does exactly what a Set .equals method is required
to do, according to the Set contract.

The problem was that AbstractSet was being extended by a class that is
apparently not intended to be used as a Set implementation. The
inherited .equals method was not an appropriate .equals method for Node.

Patricia

[toc] | [prev] | [next] | [standalone]

#20465

On Tuesday, December 18, 2012 4:39:27 AM UTC-6, lipska the kat wrote:
> On 18/12/12 08:13, 
> 
> > In the following code Node is an abstract class and both Gate and
> 
> > Monitor are extensions of Node. a and b are distinct objects yet
> 
> > a.equals(b) is returning true.
> 
> >
> 
> > public class Foo {
> 
> >      public static void main(String[] argv){
> 
> > 	Node a = new Gate();
> 
> > 	Monitor b = new Monitor();
> 
> > 	System.out.println(a.equals(b)); // -->  prints 'true'
> 
> >      }
> 
> > }
> 
> 
> 
> According to the documentation the contract for equals on instances of 
> 
> class Object is as follows
> 
> 
> 
> "The equals method for class Object implements the most discriminating 
> 
> possible equivalence relation on objects; that is, for any non-null 
> 
> reference values x and y, this method returns true if and only if x and 
> 
> y refer to the same object (x == y has the value true)."
> 
> 
> 
> This is obviously the not the case in your example above.
> 
> Does the class Node or any of it's superclasses override the equals method ?
> 
> 
> 
> The following code returns false as expected
> 
> 
> 
> public abstract class Foo {
> 
> 
> 
>     public static void main(String args[]){
> 
>        Foo bar = new Bar();
> 
>        Baz baz = new Baz();
> 
>        System.out.println(bar.equals(baz));
> 
>     }
> 
> }
> 
> 
> 
> class Bar extends Foo{}
> 
> 
> 
> class Baz extends Foo{}
> 
> 
> 
> ...
> 
> 
> 
> However, add the following method to the class Foo
> 
> 
> 
> public boolean equals(Object obj){
> 
>     return true;
> 
> }
> 
> 
> 
> and re-run the code and we get true.
> 
> 
> 
> Has someone been messing with equals ?
> 
> 
> 
> lipska
> 
> 
> 
> -- 
> 
> Lipska the Kat�: Troll hunter, sandbox destroyer
> 
> and farscape dreamer of Aeryn Sun

Thanks for your response,

I see where the problem is. I do not directly implement equals, however Node is an extension of AbstractSet which does redefine equals. As it turns out I was in the process of rewriting Node so that it no longer extends AbsteractSet when the anomaly popped up in test code, so it is actually a mote point.

[toc] | [prev] | [next] | [standalone]

#20477

plewto@gmail.com writes:

>
> Thanks for your response,
>
> I see where the problem is. I do not directly implement equals, however Node is an extension of AbstractSet which does redefine equals. As it turns out I was in the process of rewriting Node so that it no longer extends AbsteractSet when the anomaly popped up in test code, so it is actually a mote point.

And in terms of set equality the test objects are indeed equal, since
each represents the empty set.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#20478

On 12/18/2012 1:24 PM, Jim Janney wrote:
> plewto@gmail.com writes:
>
>>
>> Thanks for your response,
>>
>> I see where the problem is. I do not directly implement equals,
>> however Node is an extension of AbstractSet which does redefine
>> equals. As it turns out I was in the process of rewriting Node so
>> that it no longer extends AbsteractSet when the anomaly popped up
>> in test code, so it is actually a mote point.
>
> And in terms of set equality the test objects are indeed equal,
> since each represents the empty set.
>

The AbstractSet equals method being inappropriate for Node is a symptom
of Node not being a Set. I think changing it to not extend AbstractSet
is a good move.

Patricia

[toc] | [prev] | [next] | [standalone]

#20459

On 12/18/2012 12:13 AM, plewto@gmail.com wrote:
> 	Node a = new Gate();
> 	Monitor b = new Monitor();
> 	System.out.println(a.equals(b)); // --> prints 'true'
...
> The underlying production code is a bit complex to include here. My

This is a red flag.  The code should not be so complex that you can't 
show us what is really going on.  If it *is* too complex, then likely 
the issue is the complexity itself.

However, I think Roedy zeroed in on the most likely cause.  Your 
abstract class, Node (or some superclass), implements equals() 
*incorrectly* and is returning true when it should not.  Probably Node() 
should not implement equals() at all.

Show us the implementation of equals() for Node (and probably Gate too, 
that version of equals() could also be borked in the example you gave) 
and we'll point out the error.

[toc] | [prev] | [next] | [standalone]

#20462

On Tuesday, December 18, 2012 12:24:44 PM UTC-6, markspace wrote:
> On 12/18/2012 12:13 AM,
> 
> > 	Node a = new Gate();
> 
> > 	Monitor b = new Monitor();
> 
> > 	System.out.println(a.equals(b)); // --> prints 'true'
> 
> ...
> 
> > The underlying production code is a bit complex to include here. My
> 
> 
> 
> This is a red flag.  The code should not be so complex that you can't 
> 
> show us what is really going on.  If it *is* too complex, then likely 
> 
> the issue is the complexity itself.
> 
> 
> 
> However, I think Roedy zeroed in on the most likely cause.  Your 
> 
> abstract class, Node (or some superclass), implements equals() 
> 
> *incorrectly* and is returning true when it should not.  Probably Node() 
> 
> should not implement equals() at all.
> 
> 
> 
> Show us the implementation of equals() for Node (and probably Gate too, 
> 
> that version of equals() could also be borked in the example you gave) 
> 
> and we'll point out the error.

It is complex because it is a large application. I can either post the several hundred lines of source or the the 6 which adequately illustrates the point. Node does not implement equals at all as you say

[toc] | [prev] | [next] | [standalone]

#20467

On 18/12/2012 1:48 PM, plewto@gmail.com wrote:
> On Tuesday, December 18, 2012 12:24:44 PM UTC-6, markspace wrote:
>> Show us the implementation of equals() for Node (and probably Gate too,
>> that version of equals() could also be borked in the example you gave)
>> and we'll point out the error.
>
> It is complex because it is a large application. I can either post the several hundred lines
 > of source or the the 6 which adequately illustrates the point. Node 
does not implement equals
 > at all as you say

Roedy suggested Gate, not Node, might implement "equals". Does it?

There's likely not much people can do to help without more context. The 
"6 lines" don't adequately "illustrate the point" because from them 
alone nobody can say for sure what your problem is. Roedy's guess might 
be the best advice you're going to get.

[toc] | [prev] | [next] | [standalone]

#20472

On Tuesday, December 18, 2012 1:01:51 PM UTC-6, David Lamb wrote:
> On 18/12/2012 1:48 PM, p...mail.com wrote:
> 
> > On Tuesday, December 18, 2012 12:24:44 PM UTC-6, markspace wrote:
> 
> >> Show us the implementation of equals() for Node (and probably Gate too,
> 
> >> that version of equals() could also be borked in the example you gave)
> 
> >> and we'll point out the error.
> 
> >
> 
> > It is complex because it is a large application. I can either post the several hundred lines
> 
>  > of source or the the 6 which adequately illustrates the point. Node 
> 
> does not implement equals
> 
>  > at all as you say
> 
> 
> 
> Roedy suggested Gate, not Node, might implement "equals". Does it?
> 
> 
> 
> There's likely not much people can do to help without more context. The 
> 
> "6 lines" don't adequately "illustrate the point" because from them 
> 
> alone nobody can say for sure what your problem is. Roedy's guess might 
> 
> be the best advice you're going to get.

Yes I understand that. In fact, as I pointed out in a subsequent post, none of my code defines equals, Node was however extending AbstractSet which does redefine it. Really All I was looking for was a general direction I might look and not to burden anyone with large blocks of code. Node is 212 lines, Gate is 67, Monitor another 85, none of which even once mentions the word "equals"  

My issue with Roedy's response was not the helpful suggestion to look at super classes but rather that it comes off as lecturing, and frankly rather condescending.

[toc] | [prev] | [next] | [standalone]

#20473

On Tuesday, December 18, 2012 2:14:58 PM UTC-6, ple...@gmail.com wrote:
> On Tuesday, December 18, 2012 1:01:51 PM UTC-6, David Lamb wrote:
> 
> > On 18/12/2012 1:48 PM, p...mail.com wrote:
> 
> > 
> 
> > > On Tuesday, December 18, 2012 12:24:44 PM UTC-6, markspace wrote:
> 
> > 
> 
> > >> Show us the implementation of equals() for Node (and probably Gate too,
> 
> > 
> 
> > >> that version of equals() could also be borked in the example you gave)
> 
> > 
> 
> > >> and we'll point out the error.
> 
> > 
> 
> > >
> 
> > 
> 
> > > It is complex because it is a large application. I can either post the several hundred lines
> 
> > 
> 
> >  > of source or the the 6 which adequately illustrates the point. Node 
> 
> > 
> 
> > does not implement equals
> 
> > 
> 
> >  > at all as you say
> 
> > 
> 
> > 
> 
> > 
> 
> > Roedy suggested Gate, not Node, might implement "equals". Does it?
> 
> > 
> 
> > 
> 
> > 
> 
> > There's likely not much people can do to help without more context. The 
> 
> > 
> 
> > "6 lines" don't adequately "illustrate the point" because from them 
> 
> > 
> 
> > alone nobody can say for sure what your problem is. Roedy's guess might 
> 
> > 
> 
> > be the best advice you're going to get.
> 
> 
> 
> Yes I understand that. In fact, as I pointed out in a subsequent post, none of my code defines equals, Node was however extending AbstractSet which does redefine it. Really All I was looking for was a general direction I might look and not to burden anyone with large blocks of code. Node is 212 lines, Gate is 67, Monitor another 85, none of which even once mentions the word "equals"  
> 
> 
> 
> My issue with Roedy's response was not the helpful suggestion to look at super classes but rather that it comes off as lecturing, and frankly rather condescending.

Im sorry I meant markspace's responce not Roedy's

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web