Yes, the default implementation is Object's (generally speaking; if you inherit from a class that redefined equals and/or hashCode, then you'll use that implementation instead).

From the documentation:

equals

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).

hashCode

As far as is reasonably practical, the hashCode method defined by class Object returns distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)

Yes by default equals method implements == in Object class . But you can Override the equals method in your own class to change the way equality is done between two objects of the same class. For example the equals method in String class is overridden as follows:

public boolean equals(Object anObject) {
          if (this == anObject) {
              return true;
          }
          if (anObject instanceof String) {
              String anotherString = (String)anObject;
              int n = count;
              if (n == anotherString.count) {
                  char v1[] = value;
                  char v2[] = anotherString.value;
                  int i = offset;
                  int j = anotherString.offset;
                  while (n-- != 0) {
                      if (v1[i++] != v2[j++])
                          return false;
                  }
                  return true;
              }
          }
          return false;
      }

So this is the reason that for the following code:

String s1 = new String("java");
String s2 = new String("java");

s1==s2 returns false since both are referencing different objects on heap. Whereas s1.equals(s2) returns true since now the equals being called is what defined within String class where String objects are compared on the basis of contents of String.

I'm going to answer your question with reservations, but you should know that you are hurting yourself if the intent of the question was to get you to learn and your solution was to ask StackOverflow. That aside...

This behavior is intentional.

The default equals() method on java.lang.Object compares memory addresses, which means that all objects are different from each other (only two references to the same object will return true).

java.lang.Integer overrides this to compare the value of the Integers, so two different Integers both representing the number two compare equal. If you used == instead, you would get false for both cases.

Standard practice in Java is to override the equals method to return true for objects which have the same logical value, even if they were created at different times (or even with different parameters). It's not very useful to have objects representing numbers if you don't have a way to ask, "do these two things represent the same value?".

Incidentally, and this is a tangent here, Java actually keeps a cache of Integer objects for small values. So sometimes you may get two Integer objects where even the == operator will return true, despite you getting them from two different sources. You can even get code that behaves differently for larger integers than it does for smaller, without having it look at the integral values!

The signature of Object.equals() is public boolean equals(Object). If you define a method public boolean equals(MyClass), you're adding a new method, with a different signature, instead of overriding (or redefining, if you prefer) the Object.equals() method.

Since all the collections call the Object.equals() method, your new method would never be called by anybody except your own code, and would thus be almost useless. For example, if you create a Set<MyClass>, it will consider that two instances are different, although your equals(MyClass) method considers them equal.

No. Classes with implementations always win over default methods, so having a default hashCode or equals can never be invoked and therefore is forbidden.