Need clarification on Object.equals.

[plewto]

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

 

[Roedy Green]

Gate or one of its superclasses is implementing equals.

 

[markspace]

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.

 

[plewto]

On 12/18/2012 12:13 AM,






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

 

[plewto]

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.

 

[David Lamb]

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.

 

[plewto]

does not implement equals




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, noneof 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.

 

[plewto]

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 rathercondescending.

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

 

[Stefan Ram]

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

The general direction would be to look up the documentation
of »Gate«, especially Gate#equals.

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.

The following also prints »true« for possibly good reasons
(depending on the semantics of the classes, which is not
given here). At least it shows that this can happen without
overriding »equals«.

class Node extends java.io.File{ public Node(){ super( "alpha" ); }}
class Gate extends Node{}
class Monitor extends Node{}

public class Main
{ public static void main( final java.lang.String[] args )
{ Node a = new Gate();
Monitor b = new Monitor();
java.lang.System.out.println( a.equals( b )); }}

 

[Lew]

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

Wow. You really are a piece of work.

You come here asking people to volunteer assistance to you out of the goodness of their hearts.

markspace wrote nothing at all to justify your remark. He was objective, and offered to review
your code for you. He gave you advice on how to present the code so that
kind volunteers can help. You respond with this garbage instead of thanks?

What the hell is wrong with you?

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.

That's your misunderstanding. How about you read the Java tutorials to find out
what the truth is about 'equals()'?

 

[Jim Janney]

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.

 

[Arne Vajhøj]

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.

If you post complete code illustrating the problem, then
it can be solved in a few minutes.

Our telepathic abilities are not very good.

Arne

 

[Arne Vajhøj]

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

Those 6 lines are completely inadequate for any type of troubleshooting.

They contain zero new information compared to your description of the
problem in English.

Arne

 

[Arne Vajhøj]

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

You had a problem.

A problem which is relative easy to troubleshoot with
some basic Java knowledge.

You posted the problem here with absolutely no information
to help identify the problem.

What do you expect?

We can not do anything but provide some guesses the presence of
an equals in a class or parent class - and explain some basics
about how equals work.

So stop whining and learn to post better questions.

Arne

 

[Arne Vajhøj]

On 12/18/2012 3:17 PM, (e-mail address removed) wrote:
[snip]


So stop whining and learn to post better question.

Now I'm not normally driven to using bad language but
What the f**k is wrong with you people.
This is Usenet, not your private little universe.

Please think before you flame.

May I suggest that you take your own advice and
read and think before posting.

The case here is that:
* OP posted a question
* the question did not provide sufficient info
to answer it
* nobody took offense of that and OP got several
replies explained that it was difficult to say,
suggested possible reasons and explained how
equals is supposed to work
* OP characterized one of the repliers
as lecturing and condescending

I suggest that you direct you anger towards OP.

Arne

 

[Arne Vajhøj]

On 12/19/2012 2:20 AM, lipska the kat wrote:
...
...

I strongly agree with this, except I would have preferred "Some people
who are regular contributors ...".

Do you agree that it is acceptable behavior calling a named
replier lecturing and condescending due to this post:

<quote>
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.
<quote>

??

Arne

 

[Arne Vajhøj]

Do you agree that it is acceptable behavior calling a named
replier lecturing and condescending due to this post:

<quote>
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.
<quote>

??

My point is that while newbies do have a "allowed to post
stupid questions" card, then they do not have a "allowed
to insult others without being criticized for it" card.

Arne

 

[Arne Vajhøj]

On 12/19/2012 6:22 AM, Patricia Shanahan wrote:
On 12/19/2012 2:20 AM, lipska the kat wrote:
...

[snip]


My point is that while newbies do have a "allowed to post
stupid questions" card, then they do not have a "allowed
to insult others without being criticized for it" card.

Your arrogance is almost beyond belief. Listen to yourself
You really do think that you are in some way qualified to pass judgment
on what is a stupid question and what isn't.

Congratulations you completely missed the point.

This is USENET, you don't own it, you don't have the right to tell
people what they can and cannot post,

And you are trying to do what?

Arne

 

[Joshua Cranmer]

On 12/19/2012 6:22 AM, Patricia Shanahan wrote:
On 12/19/2012 2:20 AM, lipska the kat wrote:
...

[snip]


My point is that while newbies do have a "allowed to post
stupid questions" card,

Your arrogance is almost beyond belief. Listen to yourself
You really do think that you are in some way qualified to pass judgment
on what is a stupid question and what isn't.

I would suggest that you finish reading entire posts before starting
yelling matches, for if you had finished the sentence (assuming basic
fluency in reading comprehension), you would have learned that Arne was
opining that the criterion for what should be considered socially
acceptable by this newsgroup isn't the quality of the question but
rather by whether or not it is insulting. Also note that there was in no
way any attempt to delineate specifically what class of questions
corresponds to "stupid questions," which is apt because the entire point
of the post was to postulate the nonimportance of such a class.

Unless you were trying to be ironic.

 

[Lars Enderin]

2012-12-19 16:05, lipska the kat skrev:

On 19/12/12 14:09, Arne Vajhøj wrote:
On 12/19/2012 9:07 AM, Arne Vajhøj wrote:
On 12/19/2012 6:22 AM, Patricia Shanahan wrote:
On 12/19/2012 2:20 AM, lipska the kat wrote:
...

[snip]


My point is that while newbies do have a "allowed to post
stupid questions" card, then they do not have a "allowed
to insult others without being criticized for it" card.

Your arrogance is almost beyond belief. Listen to yourself
You really do think that you are in some way qualified to pass judgment
on what is a stupid question and what isn't.

Congratulations you completely missed the point.

No I didn't and I quote

"My point is that while newbies do have a "allowed to post
stupid questions" card"

Who 'allows' them to post stupid questions.
You ?

Who decides who is a newbie
You ?

Who decides it is a stupid question
You ?

And before you use the 'community' card

Who made you the spokesperson
You ?

Well ?

You're overreacting, in a big way (and there should be no space before
?). You completely missed the spirit (and point) of Arne's response(s).