This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
== is used to determine reference equality. In other words, are two variables (i.e. references) referencing or "pointing" to the same object. .equals() is used to determine if two objects are "equal". What makes two objects equal is up to the object. More on that in a little bit.
I personally refer to "==" as "reference equivalence", or just "equivalence" for short; so I read "x == y" as "Is x equivalent to y". And I call ".equals()" equality; so I read "x.equals(y)" as "Is x equal to y"; (Note that these are my terms and not official.)
Here's some examples using a calendar object:
And here is the output:
Did you notice how calFour's value changed when we added a day to calOne? This is because calOne and CalFour are referencing the same object. Try typing up the program and running it. Change things and make sure you get the results you expect. I find the Calendar class a good one to use when playing around with equality. I would recommend that you not use Strings when trying things with == and .equals(). The String class has some specialness to it; it's an immutable class and, for issues of memory management, the JVM "handles" it differently than most other classes. So you will sometimes get unexpected results. Typically, you want to avoid using == with Strings. When you get farther along in your programming knowledge, you'll learn about that.
Note that it would be unusual to use == for two references within the same method like we did above. (we did for demonstration purposes.) Since we said calFour = calOne in the method, we know that calOne == calFour is true. (unless we had something in an if block that may change it and we later want to test to see if it has been changed). So more often == is used when an object is passed into a method and we want to see if it is referencing the same object as another reference. Overall, equals() is typically used far more often (on objects) than == is.
As I mentioned above, it is up to the type of object -- in its equals() method -- to determine what makes two of them equal. For example, what makes two people equal? If I use just their name, then two different people with the same name would show as being equal.
But sometimes we may decide two object are equal even if one or more of their properties (i.e. variables) are not equal. For example, we may have a program that has a "Car" object that will return true for two cars even if their colors are different. Why? Because in the context of that application, color doesn't matter, so it was decided that it would be ignored when comparing for equality. Yet another application may decide that color is important when determining if two cars are equal. Still, a third application may decide that two cars are equal only if they are the same physical car, and therefore looks at the VIN (Vehicle Identification Number) to determine equality. So in this third application, even if the cars are the same make, model, and color, with the same accessories, they are not equal if they have different VINs; whereas in the second application they would be equal.
Because of this, you should always carefully read the javadoc for an .equals() method to determine how that object determines if two objects are equal. For example, the Calendar object we used above can also hold a time. (since we didn;t spcify one, it defaults to midnight.) So is 5 July 2008 10:05AM equal to 5 July 2008 11:12PM? In some applications the time may not matter. In others it does. See if you can read Calendar.equals() javadoc and determine if these two dates (same day, different times) are equal or not as far as the Calendar class is concerned. Then change the above code to test your answer.
It's also important to make sure that an Object overrides the equals method. The equals() method is defined in the Object class. So all objects inherit the default equals() method. But if an object does not override the method, the equals method ends up acting more like ==. This is because until you define what makes two "Things" or two "Widgets" equal by overriding the equals method, there is no way to tell. [ July 05, 2008: Message edited by: Mark Vedder ]
Oh, something else I should mention... the above discussion is for Objects. When used on primitives (i.e. int, short, long, double, float, byte, etc.), == acts more like equals(). In other words, it determines if the two values are equal.
all the primitive type wrapper classes override the Object.equals() method to compare the value of the objects; the default Object.equals() checks if the variables reference the same object. equals(Object anObject)Compares this string to the specified object
== operator is used to compare contents of two string reference variables pointing to different String objects