3

on the oracle java documentation, equals() from list says two lists are defined to be equal if they contain the same elements. But from object class equals() return true only if their hash code is equal. It means equals() from list overrides equals method from object class. And it's same for equals() from string. As long as they have same characters, they return true.

so whenever I declare a type as String, or use list classes like arraylist equals() are overriden automatically righT?

Si Yo
  • 67
  • 6
  • That's correct. – shmosel Dec 06 '18 at 23:43
  • Possible duplicate of [What is the difference between == vs equals() in Java?](https://stackoverflow.com/questions/7520432/what-is-the-difference-between-vs-equals-in-java) – Krease Dec 07 '18 at 22:17

3 Answers3

4

equals() are overridden automatically righT?

Answer : Yes absolutely right, If you are asking overriden .equals() method is invoked automatically at run time

**Object class is parent class for every class in java and it consist of .equals() method which compares the object references

But String class, Wrapper classes (Integer,Long etc..) and Collections Classes (ArrayList, hashSet etc..) are overridden .equals() method to compare content in object instead of object references

to avoid confusions here is the clear example

public class Main2 {
public static void main(String[] args) {
    List<String> l1 = new ArrayList<>();
    l1.add(new String("hello"));
    List<String> l2 = new ArrayList<>();
    l2.add(new String("hello"));

    System.out.println(l1.equals(l2)); //true

    List<Test> t1 = new ArrayList<>();
    t1.add(new Test());
    List<Test> t2 = new ArrayList<>();
    t2.add(new Test());

    System.out.println(t1.equals(t2)); //false
    }
}

 class Test{
  }

In the above example comparing List<String> will return true because .euqals() method in String is overridden to compare content

But while comparing Lits<Test> will return false even though both objects are empty, since .equals() method in Test class is not overridden by default it will invoke Object class .equals() method which compares reference of objects as == does

Google Question object class equals method compares hashcode ?

Answer

The java.lang.Object class requires that any two objects that compare equal using the equals() method must produce the same integer result when the hashCode() method is invoked on the objects [API 2014]. The equals() method is used to determine logical equivalence between object instances.Feb 12, 2018

Ryuzaki L
  • 37,302
  • 12
  • 68
  • 98
  • 2
    There are a few incorrect / misleading things about `hashCode` here that need to be fixed - `hashCode` does NOT mean "object reference", and the default implementation of `equals` does not compare hashcodes - it compares object references. (OP is confused and relying on this information [here](https://stackoverflow.com/questions/53675015/object-equals-method-being-and-shallow-copy/53675245) – Krease Dec 07 '18 at 22:10
  • `But from object class equals() return true only if their hash code is equal.` this is what i said in my answer i believe @Krease – Ryuzaki L Dec 07 '18 at 22:31
  • `equals() return true only if their hash code is equal` -- this statement is false. You can have many objects with the same hashCode that are not equal. This has led OP to understand the default implementation of `equals` is to check the value of `hashCode`, which is also not correct – Krease Dec 07 '18 at 22:35
  • i believe this comes into picture with your own `.equals()` and `hashCode()` implementation `You can have many objects with the same hashCode that are not equal` @Krease – Ryuzaki L Dec 07 '18 at 22:40
  • Any class. [Try this](https://stackoverflow.com/questions/12925988/how-to-generate-strings-that-share-the-same-hashcode-in-java): `System.out.println("Aa".hashCode()); System.out.println("BB".hashCode());` - both will output the same hashCode – Krease Dec 07 '18 at 22:46
  • i really did not get your point, are you saying `object class equals() method will not compare hashcode` or `many objects can have same hashcode even though they don't have same content` ? @Krease – Ryuzaki L Dec 07 '18 at 22:54
  • I'm saying both of those things. In addition (with respect to the latest edits), Objects that are equal should produce the same hashCode, the reverse is not true: objects that produce the same hashCode are not necessarily equal (which is why `equals` should never compare hashCode values). This rule is not automatic, but should be implemented properly by the developer writing the `equals` and `hashCode` methods. – Krease Dec 07 '18 at 23:00
  • exactly, thanks for clarification, in my answer i never said `objects that produce the same hashCode are must be equal` and i agree with you it's completely developer responsibility while writing equals and hashCode methods – Ryuzaki L Dec 07 '18 at 23:07
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/184901/discussion-between-krease-and-deadpool). – Krease Dec 07 '18 at 23:10
3

equals() are overriden automatically righT?

No. Methods are not overwritten "automatically".

You can look at the code - both classes have their own implementation of equals and hashCode. This implementation is what is used at runtime. If you're writing your own class, you will likely implement equals and hashCode.

But from object class equals() return true only if their hash code is equal.

I think you (and the original version of the other answer) are misunderstanding the documentation on equals:

Indicates whether some other object is "equal to" this one.

The equals method implements an equivalence relation on non-null object references:

    It is reflexive: for any non-null reference value x, x.equals(x) should return true.
    It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
    It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
    It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
    For any non-null reference value x, x.equals(null) should return false. 

The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true).

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

The only part of this that refers to hashCode is at the end, which specifies that equal objects must have equal hash codes - this isn't automatic, it's by convention so things like HashMap will work.

Comparing hashCode values is NOT the default implementation of equals, and should NEVER be the implementation of equals - it is possible to have multiple non-equal objects with the same result for hashCode. The rule is to make sure your hashCode implementation returns the same value if objects are equal.

As an example, both of these will output the same hashCode, but are clearly not equal:

    System.out.println("Aa".hashCode());
    System.out.println("BB".hashCode());

Recommended further reading: this related question.

Krease
  • 15,805
  • 8
  • 54
  • 86
0

No, .equals() would not magically get overwritten when String are getting compared in list.

the String Class in java already has the .equals() method overwritten in its definition to compare characters by default.

meaning, even without a list if you do this:

String a = new String("abc");
String b = new String("abc");
System.out.println(a.equals(b)); 

Then, your output would be true

refer this: https://docs.oracle.com/javase/7/docs/api/java/lang/String.html

AppleCiderGuy
  • 1,249
  • 1
  • 9
  • 16