Doubt regarding getClass() and equals()

[Prasad Joglekar]

Hi all,

Please let me know if the following statement is true or false (and of course, why)

If a.equals(b), then a.getClass == b.getClass()

{ I think it is true i checked out some examples as well, but the Whizlabs simulator disagrees }

Thanks and Regards,
Prasad

[vidya sagar]

Please let me know if the following statement is true or false (and of course, why)

If a.equals(b), then a.getClass == b.getClass()

HI Prasad

  
class getclassdemo
{
public static void main(String as[])
{
String s ="vidya";
Object o="vidya";
System.out.println(s.equals(o));//1
                System.out.println(s.getClass() == o.getClass()); //2
        }
}

while running this program it shows compiler error saying incomparable types: java.lang.String and java.lang.Class


BUt when u comment line 2, line 1 displays true......

I hope this may be a reason...........?

[James Carman]

This is not necessarily true in all cases. Consider a class that I write...

  
public class EqualsEverything
{
  public boolean equals( Object o )
  {
    return true;
  }
}

Now, if I ask an instance of "EqualsEverything" if it's equal to an instance of String, it will return true. But, their classes are not equal.

[Tony Morris]

No it is not true, and does not form part of the contract.
However, checking the type with something other that the class might break symmetry (which does form part of the contract). However, this problem will never occur if you declare all classes final (since a non-final class implies a serious design flaw).

[James Carman]

Originally posted by Tony Morris:
(since a non-final class implies a serious design flaw).[/QB]

What? That's an interesting statement. Care to back that up? By that rationale, the java.lang.Object class should be final, no?
[ May 06, 2005: Message edited by: James Carman ]

[Tony Morris]

What? That's an interesting statement. Care to back that up? By that rationale, the java.lang.Object class should be final, no?

I've tossed around the idea of writing a book, since I'd like to present this topic (and more) in such a way that even the most ignorant audience would 'see the light'.

Before that though, I plan to refute the poor job that Allen Holub has done in his presentation, where he tries to present the truth but undermines the entire value of it. This bothers me in that although I know that concrete inheritance is a serious design flaw, I acknowledge that a lot of others don't (despite being obvious given all the facts). That is, a lot of people have blindly followed this doctrine that has been taught for years, and others have tried to present the truth, but never in a way (that I feel) portrays the entire subject.

"Why extends is evil" (if you're game)
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

I am currently writing an article titled, "Why extends is not evil. A refutation of the article presented by Allen Holub, titled 'Why extends is evil'". I will publish this article on http://www.jtiger.org/ under the articles section. Time permitting (like usual). Keep watching I guess.

I just reread and noticed your comment on java.lang.Object. You're correct, Java is intrinsically broken. That is, even if you were to rewrite the entire core API, you would be tied to concrete behaviour (since java.lang.Object exposes non-final methods).
[ May 06, 2005: Message edited by: Tony Morris ]

[Tony Morris]

http://www.jtiger.org/articles/why-extends-is-not-evil.html