 The general subject of comparing objects, or object references, can be introduced concretely with strings.  Recall that String is a class, and so strings themselves are instances of this class.  The String class implements a method called equals().  This is the method that checks to see whether the contents of two different string objects are the same.

 Let two strings be declared and initialized as follows:  String myString = “Hello World”;  String yourString = “Hello World”;  The situation can be diagrammed in this way:

 Two separate objects exist, containing the same sequence of characters.  Here is an if statement containing a call to the equals() method.  In this situation the condition evaluates to true.  if(myString.equals(yourString))

 If these string values were assigned to the two references, however, the equals() method would return false:  myString = “Tra-la-la”;  yourString = “La-de-dah”;

 The complication comes when you consider the use of the operator ==.  This tests for equality of reference, not equality of contents.  In other words, it tests to see whether the objects themselves are the same, not whether their contents are the same.  I consider this to be a major pitfall for new programmers, so make sure to understand this.

 Let the two strings now be declared and initialized as follows:  String myString = “Hello World”;  String yourString = myString;  if(myString == yourString)  The situation can be diagrammed in this way:

 Only one object exists, with two references to it.  Here is an if statement containing a test of equality of reference.  In this situation the return value would be true.  if(myString == yourString)

 There are other methods in the String class that support various kinds of comparisons.  Among them are compareTo() and equalsIgnoreCase().  The first of these allows you to compare the contents of strings to see which might come first alphabetically.  The second method allows you to check for equality of contents of strings where small and capital letters don’t make a difference. This is done by returning a boolean result.

 This can be useful when taking in input from users.  Complete information on each of these methods can be found in the Java API documentation.

 The same observations that were made for comparing equality of strings can be made for comparing equality of objects in general.  Suppose you have the following two declarations and initializations:  Point2D.Double myPoint = new Point2D.Double(10, 20);  Point2D.Double yourPoint = new Point2D.Double(30, 40);

 The contents are different and the objects are different. Both the equals() method and the == would return false.  Suppose instead that the initializations were as follows:  Point2D.Double myPoint = new Point2D.Double(10, 20);  Point2D.Double yourPoint = new Point2D.Double(10, 20); 

 Now there are two different objects with the same contents.  The equals() method would return true while the == would return false.  Finally consider this case:  Point2D.Double myPoint = new Point2D.Double(10, 20);  Point2D.Double yourPoint = myPoint;

 Now both equals() and == would return true.  The references refer to the same object, and by definition the contents of the object referred to by the references are the same.

 This description of equals() and == applies to system supplied classes.  However, beware: equals() will not work this way with classes you have written.  For example, suppose I have the following objects, created using my own class:  Shampoo myShampoo = new Shampoo();  Shampoo yourShampoo = new Shampoo();

 No matter what the contents of these objects might be, the equals() method will work exactly like the ==.  In other words, for your classes it is possible to call the equals() method, but it only tests for equality of reference, not equality of contents.

 Your class inherits the method equals() from a class above it in the hierarchy.  However, the inherited implementation does not work in the desired way.  How to write an equals() method will be covered in a future unit.