If == is true , does it mean equals(Object o) also true ?

[maha anna]

We all know that the difference bet == operator and the .equals(Object o) method inherited from Object. I wanted to make sure the foll.
.equals(Object o) is true does not mean == also true.
eg. String s1 = new String("Java is cool");
String s2 = new String("Java is cool"); //(s1==s2 is false
but s1.equals(s2) true )
== is true means, .equals(Object o)ALSO true.
Is the above statement true? I can give an example for true
String s1 = new String("Java is cool");
String s2 = s1; //both == and equals(..) are true
If the ans is false Can anybody give a code example?
Because if 2 ref are same means , the object they both refer to must be same right? which means their contents shd be same.
[This message has been edited by maha anna (edited February 19, 2000).]

[Tony Alicea]

Your analysis is correct in my opinion.

[maha anna]

Thank you Tony. Can you answer this for me? Did you take the sample qstns/ mock exams multiple times? Because some things I feel I don't remember when I read the JDK . For ex. the correct syntax and inheritance etc. When I take the exams only I remember. How did you prepare? What I wanted to know was when we take the exam 2nd time /3 time etc we kind of knowing already what the qstn is going to ask and don't think that much. Can you tell me the OK way of reading and taking the test. Since you have got a VERY GOOD SCORE I think you can show some light on this I think.
Thank you
Maha Anna

[Tony Alicea]

This is always a difficult question to answer since everybody is different.
My technique was to study topics in Java to my satisfaction, and then prepare for the exam. It took 8 months from complete start with no experience in OOP to finishing last Monday with 98% score.
As for the mock tests, I left them for almost the end and didn't repeat any for the reasons that you mention. I didn't take them all at once, but these are the ones: the two by Marcus Green, the two by Barry Boone in his Java 1.1 Certification book, all the exercises in the Roberts and Heller and all the exercises in JAVA 2 EXAM CRAM book plus the mock test the same day of the real exam.
Also, all applicable exercises in the Mughal and Rasmussen book. This book has applets and introductory Swing which are NOT in the exam.
Before gEs was released it was available in a beta version for free. I took that. The ones in lawn.com are good too.

[maha anna]

Thank you Mr.Tony for your kind info.
maha anna.

[Tony Alicea]

I need to add to my statement above since I don't want to mislead anyone.
I started Java last June, starting from no OOP experience as I said, but with a lot of experience in assembly language and C (not to be confused with C++).
I DID NOT STUDY FOR THE TEST for 8 months!. Only three, tops.
I did teach myself Java at my own pace and in more detail that the exam requires. In fact, I did not know nor care about Certification until about 5 months into my studies.
I then wrote a few Java applets and programs (which are available in http://alicea.org/java ) not only to practice but one that I needed to display the HTTP header of any file on the public Web.
THEN I decided to look into Certification and for reasons that I am cutting short for brevity and which I have posted about before, I decided to go for Certification three months ago. I thought I knew my stuff and when I took the first questions of the Roberts and Heller book and failed more than a few of them, I figured that the test was not going to be easy and as such, possibly of some value after all.

[OlegP]

Obvious (but artificial) example
public class EqualsFalse {
public boolean equals(Object o)
{
return false;
}
}

[nirvan sage]

The equals() method and == operator perform different functions in the case of wrapper classes and String class,this is because the equals method by default is used to compare objects but they are overrided in these classes to compare the value.

for example

class equ
{
int x;
public equ(int y)
{
x=y;
}
public static void main(String args[])
{
equ eq = new equ(5);
equ eq1 = new equ(5);
if(eq==eq1)
System.out.println("== works");
if(eq.equals(eq1))
System.out.println("equals() works");
//none of the statements will get printed because equals //method is not overrided
}
}

[Frank Carver]

Here's a not quite so obvious or artificial example, in fact it's almost a "gotcha".

class Item
{
  private float value;
  // two Items are equal only if the values are the same
  //
  public boolean equals(Object other)
  {
    return (other instanceof Item) && (value == other.value);
  }
}

I have used this sort of idiom plenty of times, and I'm sure many people have. It seems very straightforward and reasonable. With integers, Strings etc. it works very well.
But beware It won't always work with floats and doubles. The reason is the peculiar behaviour of the NaN (not-a-number) value which all floats and double may contain. NaN is strange in that it is never equal to any other number, not even itself. So if an Item from the above class happens to contain NaN and is compared with itself, then == will be true (the addresses are the same) but equals will not.
NaN is sufficiently unusual that you may never encounter this wierdness in testing either. So just be careful with floats and doubles!