equals() evaluates the contents of an object and not its memory location

[Clemonte Johnstone]

Dear All, please could someone explain to me why true:true is the wrong answer? I thought that equals() evaluates the contents of an object and not its memory location


/* What will be the result of compiling and executing the below program?
  A) Compilation error
  B) true:true [WRONG ANSWER]
  C) false:true
  D) true:false
  E) false:false [CORRECT]

 
*/

public class _62_Question_StringBuilder {
public static void main(String[] args) {
String str = "java";
StringBuilder sb = new StringBuilder("java");

System.out.println(str.equals(sb) + ":" + sb.equals(str));
}
}

[Campbell Ritchie]

Mark Raphael Qt wrote:. . . I thought that equals() evaluates the contents of an object and not its memory location . . .

The equals() method neither evaluates the contents of an object nor its memory location. It provides a definition of equality to be used by objects of the class it is overridden in.

That API page wrote:Indicates whether some other object is "equal to" this one.

If you override the implementation, you can provide your own definition of equality which might include being the same object, having the same state of all the fields, or having the same state as in some of the fields. Please forget about “memory locations” when programming Java®. It is an object language and memory locations aren't a feature of objects, but there is an operator which tests whether two references point to the same object. The writer of the class provides the definition by how they write equals().
If you go through the documentation for Object, String, and StringBuilder, you can see which definitions of equality each uses. That determines the output of the question above.

[Stephan van Hulst]

The equals() method doesn't compare objects by identity in general. However, the default Implementation does.

StringBuilder doesn't override equals(), so it inherits the default behaviour defined in Object, which does the same as the == operator.

You can broadly subdivide classes in two categories: Value types and services.

Value types represent a fixed value and can almost always be compared to objects of the same type. They generally override equals(), hashCode() and toString(), and they often implement Comparable as well. String is an example of a value type.

Services are objects that don't represent a value, but are usually used to modify application state or create or transform other objects. Since they're not used as values, they typically don't override equals() and hashCode(). StringBuilder is an example. It is a service you use to build strings, it doesn't represent a string value itself.

Keep in mind that this is not a strictly bipartite classification. There are types that can be viewed as both value types and services. I think most collections, like Set, are good examples.

[Clemonte Johnstone]

Google defines it as such:

== should be used during reference comparison. == checks if both references points to same location or not. equals() method should be used for content comparison. equals() method evaluates the content to check the equality.

Please could you kindly explain the program for me in simple terms?

[Campbell Ritchie]

Clemonte Johnstone wrote:Google defines it as such:

Please provide a source.

. . .  == checks if both references points to same location or not.

The Java® Language Speciication (=JLS) defines it differently, and doesn't mention memory locations at all. Please look at the link I gave you earlier, under “operator”. Remember that the JLS is the definitive source; anything contradictory to it is incorrect.

. . . equals() method evaluates the content to check the equality. . . .

You have seen already that last quote is incorrect.

If you look at the documentation for the two classes involved, String and StringBuilder, you can see how they implement equals(); that should make the above example simple to understand.

[salvin francis]

For having a question mentioned in the January 2021 CodeRanch Journal, congratulations: this question earns you a cow

[Steve Warren]

If the statement to evaluate were
System.out.println(str.equals(sb.toString()) + ":" + sb.toString().equals(str));
instead of
System.out.println(str.equals(sb) + ":" + sb.equals(str));
then the output would have been "true:true" because it would be comparing String objects, not disparate classes.

As others have said, it is about how equals() is defined.  Since StringBuilder doesn't (or unless it does) define equals to compare to a String, its .equals() won't do anything useful.  However, (as I recall) the StringBuilder.toString() outputs a String representation of its contents, which in this case is "java", so then both of the following expressions are true:

sb.toString().equals(str)
str.equals(sb.toString())

Maybe that doesn't help, but hopefully it adds a different perspective.