Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
117 views
in Technique[技术] by (71.8m points)

java - Why equals method in the String class defined as equals(Object anObject) but not as equals(String anObject)?

this is equals() from String class

public boolean equals(Object anObject)
{
    if (this == anObject)
    {
        return true;
    }
    else
    {
        if (anObject instanceof String)
        {
            String aString = (String) anObject;
            if (this.coder() == aString.coder())
            {
                return this.isLatin1() ? StringLatin1.equals(this.value, aString.value) : StringUTF16.equals(this.value, aString.value);
            }
        }
        return false;
    }
}
  1. So why it is defined as equals(Object anObject) but not as equals(String anObject)? What's the point of having an opportunity to receive any object if it's return false for any other objects than String?
  2. If I create MyOwnClass should I override equals() method as
    equals(Object obj)
    or as
    equals(MyOwnClass obj)
    If as in the first option then why?

P.S.: covariance works in return type when overriding. I thought that if covariance works in return type when overriding so it must work in a function arguments too.

{
    public A foo(A o)
    {
        return new A();
    }
}

class B extends A
{
    @Override // everything OK
    public B foo(A o)
    {
        return new B();
    }
}
question from:https://stackoverflow.com/questions/65941180/why-equals-method-in-the-string-class-defined-as-equalsobject-anobject-but-not

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

No answer so far gets to the heart of the issue.

Java's typing system is covariant (until you get to generics, where you choose which variance you want).

Given that class Apple extends Fruit and class Fruit extends Object, then all Apples are also Fruits, all Fruits are also Objects, and all Apples are also Objects.

And Object, because java.lang.Object says so, has an equals(Object other) method. That means that apples must also have this method:

  1. All apples are objects.
  2. All objects have an equals(Object) method
  3. Therefore, apples have an equals(Object) method.

So why do objects have this method? Because it's useful. Because it makes ArrayList's contains(Object other) method tick, it makes java.util.Set work. Once you've decided that all Objects have an equals(Object other) method, the rest (specifically, that apples have an equals(Object other) method, which trivially returns false if you ask it if it is equal to some non-apple object) is locked in; that is now the case simply because the system we've set up here (which is a covariant typing system, where the base type all types inherit from has an equals(Object) method) dictates it must be so.

Yes, the java language spec in fact guarantees it; you can't 'remove' the equals(Object) method from Apples. However, the crux of the matter is why the java spec works like this.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...