equals method

[UPENDRA KANE]

I tried this code. I was expecting answer to be True in both cases. But NO?? equals() methode of Wrapper classes checks the contents of the object isn't it?
Where am I making mistake? Any thoughts??
Long l=new Long(10);
Integer i = new Integer(10);
if (l.equals(i)) {System.out.println("True");}
else System.out.println("l-i flase");
if (i.equals(l)) {System.out.println("True");}
else System.out.println("i-l flase");

[Viji Bharat]

Upendra:
See this explanation from Java Lang Spec or class Long (java.lang.Long) where equals method is overridden.
In class java.lang.Long
public boolean equals(Object ob)
The result is true if and only if the argument is not null and is a Long object that represents the same long value as this Long object.
The equals method is similarly overridden for Integer class too.
Hence in your example,
l.equals(i) - i is not a Long object. Hence it is false.
Similarly,
i.equals(l) - l is not an Integer object. Hence, the result is false.
HTH

[B Barnett]

Upenda:
The equals method checks for object equality, not the value.
Because one reference is to an Integer object and the other one is to Long object, this will always return false.

[Mohnish Sharma]

Upendra
You are comparing apples and oranges.
The API specification for Integer.equals() says:
public boolean equals(Object obj)
Compares this object to the specified object. The
result is true if and only if the argument is not
null and is an Integer object.
Since you are comparing an Integer and a Long, the result will always be false.
Mohnish

[parimalsharma]

Dear Upendra,
The equals method does the deep checking, whereby it checks for the contents of the object. But it applies for the same Wrappper Class only.
Nothing much !

[UPENDRA KANE]

Guys,
Sorry, for posting a stupid Q. I should have checked with the API documentation before posting the Q.
Mohnish,
You are correct. I was comparing Apple with Orange...
Thanks for the responces...

[Manish Singhal]

Upendera don't you think that this forum is to clear our doubts no matter what is the level of doubt. So I think no question is stupid unless it is asked for fun.

Guys am I wrong !!! Be frank.
Do expect questions like that from me.... and I hope to get positive answers for those.
Manish

[Jane Griscti]

Manish,
You're right! We are all here to learn and when you're learning there's no such thing as a stupid question
Upendra, You may have been confused by the equals() because when it's used with Strings it checks the value vs the object; but this is because String specifically overrides the java.lang.Object equals() method, as does the Boolean class.
Hope that helps.
------------------
Jane

[Mapraputa Is]

Upendra, your question was not stupid at all. Analogy with apples and oranges doesn't work well in this case. Integers and longs (as primitive data types)ARE comparable, when we code smth like
int i = 1;
long j = 1;
if (i=j) ...
it works fine.
When I met this questions for the first time, I was also puzzled with results. I always thought that programs (methods in particular) are created to be useful. So I expected method equals to be useful = allow comparing Integers and Longs. It doesn't. I still think that the reason is not fundamental impossibility to implement such comparison, but Java designer's arbitrary (and not very OO) decision.
I am waiting for somebody to correct me.

[This message has been edited by Mapraputa Is (edited October 03, 2000).]

[Kishan Kumar]

Mapraputa,
int i = 1;
long j = 1;
if (i=j) ....
I think you missed a "=" sign.
if (i=j) would never compile in Java, it should have been
if(i == j)....
Everyone knows you would have intended this only but still new
buddies registering in JavaRanch should not get confused.
I am also feeling that equals() methods is too harsh in comparing
objects. And can anybody please explain me why StringBuffer class
does not override equals() method. I am at a loss to find out why
this injustice is done to StringBuffer class.

------------------
Regards,
V. Kishan Kumar

[kishor kotecha]

No stupid question Upendra. I basically learned a few things in that and thanks for the questions and all the answers.
Post more questions and we all will learn from such.
- Regards.

[Sathvathsan Sampath]

I just have an observation:
The equals() method is overriden by almost all the immuatable classes like String, wrapper classes.
So, does this have anything to do with the delibrate design of not overriding the equals() method of the StringBuffer class(a mutable class)?
I wish someone could come with some explantion.
And Mapraputa, I wouldn't entirly agree with you on the comment of arbitary design choice for the wrapper classes. But, I must admit that neither do I have any answer for that.
But, something deep inside within myself says that when overriding an equals(Object ob) method it'd be more sensible to do the comparision provided ob is an instanceof the class overriding the equals() method.
One of the reasons I'd opt for such a decision is you really wouldn't know how many classes may come in future and u really can't take into account of all the possible classes applicable for the equals() method.
Maybe someone could give a better justification
Also, typically in a OOP, the imple

[Mapraputa Is]

Kishan Kumar:
You are right, if (i=j) should be if(i == j) � shame on me�
All new buddies registering in JavaRanch, forgive me! Never write code like this!
To redeem my sin, here is a trick you should be aware of (it�s from one of mock exams, maybe you have already seen this question)
boolean var1 = false;
boolean var2 = true;
If ( var1 =var2)
// bla-bla-bla-statement which will be executed
else
// another-bla-bla-bla-statement which will not be executed
here inside of if statement var1 instead of being compared to var2 is assigned value of false and then the whole expression is evaluated as �true�.
Just to show what a horrible thing may happen if somebody (like Mapraputa) forgets to put the second �=��
Sampath:
If I understand you right, you think design choice for the wrapper classes equals method implementation wasn�t arbitrary, but you cannot explain why this decision was made. Agree, probably Java designers had something in mind (at least, I hope so! ) but it is not obvious, what exactly� Somebody ehnightened, please, explain!

[Mapraputa Is]

Oops, boolean example is not "from one of mock exams", it is from famous Java Rule Round-Up!

[Ajith Kallambella]

My thoughts about <code>equals</code> method for <code>StringBuffer</code> class -
It is often the case that .equals() should be redefined, but this requires care. In the example with StringBuffer, redefining .equals() at this point would change the semantics of any Hashtable of StringBuffers that may have been created. This is because if two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
There are many useful notions of equality. Other folks may prefer the default object equality. Consider for example the capacity property of StringBuffer. Are two Stringbuffers equal if they have the same characters but different capacity?
If you want StringBuffers that redefine equality in the way you want, go ahead and write your own Stringbuffer class to do what you want. The easiest way to do this is by creating a wrapper for StringBuffer class. That seems to be the only way at this point of time. A lot of people have requested Sun to consider this as an enhancement request.
Comments welcome
Ajith
[This message has been edited by Ajith Kallambella (edited October 05, 2000).]

[Sathvathsan Sampath]

Nice explanation Ajith.
So, thats probably why we can expect almost all immutable final classes to have overridden the equals() method.
And, just another point, StrinBuffer is a final class and cannot be extended. I just felt that this point was not explicit in your comments.

------------------
- Sathvathsan Sampath
[Thanks Sampath!..I have edited my post for clarity - Ajith ]
[This message has been edited by Ajith Kallambella (edited October 05, 2000).]

[Dhamu. Com]

Dear friends!
The above code (fisrt block) works with following.
Long L = new Long(9);
if(L.equals(new Long(9)))System.out.print("True");
o/p will be true.

[Sathvathsan Sampath]

Hey Dhamu,
I remember getting a very very similar question to what u have mentioned
Anyway..... we need to lookout for these kind of questions, but it should be of no problem at all if our concepts are clear.

------------------

- Sathvathsan Sampath