Diff between equals() and == operator

[Seetesh Hindlekar]

Hi,
Cld anyone highlight
1. Main differences between Object's equals() method and the == operator
2. If String didnt have the equals() method then how can we compare 2 strings?
Rgds,
Seetesh

[Mani Ram]

Originally posted by Seetesh Hindlekar:
1. Main differences between Object's equals() method and the == operator

The == operator is used to check whether 2 things are equal or not.
In case of primitives, this operation returns true if the value of both the things are equal.
For example,
if a=7 and b=7, then (a == b) returns true.
When used with references, this operation returns true, if both the variables point to the same object.
For example,

MyObject a = new MyObject();
MyObject b = a;

In this case, (a == b) returns true, since both a & b refer to the same object.
Reg equals() method:
The equals() method in the object class does exactly what the '==' operator does. Other classes can override this method if they wish.
Consider the following example,

Integer i = new Integer(1);
Integer j = new Integer(1);

In this case, (i == j) returns false because, the references i & j points to different objects.
On the otherhand, i.equals(j) returns true, because the equal() method in the Integer class is overridden in a way that the actual values are compared.

[Mani Ram]

Originally posted by Seetesh Hindlekar:

2. If String didnt have the equals() method then how can we compare 2 strings?

You can check the individual characters in the String objects to see whether they are equal.

[Jeroen Wenting]

boolean areEqual(String s1, String s2)
{
  return s1.indexOf(s2)!=-1 && s1.length()==s2.length();
}

would return true if s1 contains s2 and has the same length, thus if they contain the same data.
This would be equivalent to s1.equals(s2) but not to s1 == s2 (which is not guaranteed to give true if s1.equals(s2).

[Seetesh Hindlekar]

Hi all,
Thanks for ur post.
String language = "english";
String country = "english";
if (language.length() == country.length() )
{
for(int i=0;i<language.length();i++)
{
System.out.println("lang substr "+language.substring(i,i+1));
System.out.println("countr substr "+country.substring(i,i+1));
//if (language.substring(i,i+1) == country.substring(i,i+1) )
if (language.substring(i,i+1).equals(country.substring(i,i+1)) ) //linex
{ System.out.println("language country SUBSTRING == ");
}
}
}
How do I go a round about without using the .equals method on linex mentioned above?
Any clues?
Thks once again.
Rgds,
Seetesh

[sever oon]

The == operator compares references to objects. So if you write:

Object a = new Object();
Object b = a;

You have two variables, a and b, referencing the exact same object on the heap (they both point to the same chunk of memory containing the object you created). That's what the == operator does.
The equals() method is designed to perform a "comparison for equality" on two references. For most objects, this means that you're talking about two different objects and you want to know if they contain equivalent content. However, for some objects, it simply does the same as the ==. To know for certain you have to read the javadocs associated with that object. For other objects, it's sort of ambiguous. Take the case of the String, for example...
One thing you may or may not know about Strings is that they are "interned" automagically by the JVM. So, if you create two Strings that both refer to the string of characters "abc", given long enough, the JVM will figure this out and discard one of the objects. This will not cause you a problem though, because it will adjust the reference of the discarded object to point to the other String that has the same character sequence. Note that Strings are immutable objects as well (once created, they cannot be changed until they are garbage collected). So it's completely transparent.
The confusion comes in when you're trying to figure out whether to compare two Strings by == or equals(). Let's say you write:

String s = "abc";
String t = s;

These two Strings will immediately point to the same object in memory because you directly assigned a reference to another variable. So, both equals() and == comparisons will return true. However, if you write:

String u = "def";
String v = "def;

If you immediately perform a == compare, it is likely that the JVM has not yet had time to check these two and intern them into the pool it keeps of all Strings. So, == will return false, informing you that these two references point to distinct objects. If you come back some time later and do a == compare, though, you may be surprised to find that the JVM has interned them in the interim.
Of course, if you read the javadocs for the equals() method for the String class, it does a character compare, so it would always return true for these two Strings u and v because they represent the same sequence of characters. (In fact, if the JVM is smart, the equals() method of String would, if the result is true, tell the JVM that the two Strings are equal so it could immediately intern them or at least schedule them for interning later.)
Keep in mind when writing your own objects, if you implement an equals() method that doesn't simply inherit from a JVM platform object, you must make sure that hashCode() is also overridden if necessary in your object. For example, say you write a class that has some weird, specialized idea of what equals() should do. You want to make sure you fully understand the contract defined by java.lang.Object and make sure you follow those same rules. Remember, subclasses can only follow *more* restrictive rules than their superclasses--you can't loosen a contract. Always remember that other code in the system can deal with your object polymorphically as an Object, and you'll be expected to meet the rules defined by that class as a subset of the rules your specific type follows.
sev

[Seetesh Hindlekar]

Hi all,
Thks for ur posts.
Is the conclusion for == operator for Strings right :=
== operator compares 2 objects to determine if they are same object in memory. It is possible for two String objects to have same value, but located in different areas of memory.
Rgds,
Seetesh