为什么 Java 不允许在枚举中覆盖 equals(Object)？

Question

I've noticed that the following snippet...

@Override
public boolean equals(Object otherObject) {
    ...
}

...is not allowed for an Enum, since the method equals(Object x) is defined as final in Enum . Why is this so?

I cannot think of any use case which would require overriding equals(Object) for Enum. I'm just curious to know the reasoning behind this behavior.

Answer 1

Anything but return this == other would be counter intuitive and violate the principle of least astonishment . Two enum constants are expected to be equal if and only if they are the same object and the ability to override this behavior would be error prone.

Same reasoning applies to hashCode() , clone() , compareTo(Object) , name() , ordinal() , and getDeclaringClass() .

---

The JLS does not motivate the choice of making it final, but mentions equals in the context of enums here . Snippet:

The equals method in Enum is a final method that merely invokes super.equals on its argument and returns the result, thus performing an identity comparison.

Answer 2

There is already provides a strong intuitive notion of what it means for instances (values) of an enum to be equal. Allowing the overloading the equals method would lead to that notion being violated, leading to unexpected behavior, bugs and so on.

Answer 3

正是因为Java设计者无法想到任何可以想象的用于覆盖Enum.equals（Object）的用例，该方法被声明为final - 所以这样的覆盖是不可能的。

Answer 4

Sometimes we need to deal with data that does not conform to Java naming standards. It would be nice to be able to do something like this:

public enum Channel
{
    CallCenter("Call Center"),
    BankInternal("Bank Internal"),
    Branch("Branch");

    private final String value;

    Channel(String value)
    {
        this.value = value;
    }

    @Override
    public String toString()
    {
        return value;
    }

    public static Channel valueOf(String value)
    {
        for (Channel c : Channel.values())
            if (c.value.equals(value))
                return c;
        return null;
    }

    @Override
    public boolean equals(Object other) 
    {
        if (other instanceof String)
            other = Channel.valueOf((String)other);
        return super.equals(other);
    }
}

The "String" class would need to be modified to accommodate...

public boolean equals (Object object) {
    if (object == this) return true;
    if (object instanceof Enum) 
        object = object.toString();
    if (object instanceof String) {
        String s = (String)object;
        // There was a time hole between first read of s.hashCode and second read
        //  if another thread does hashcode computing for incoming string object
        if (count != s.count ||
            (hashCode != 0 && s.hashCode != 0 && hashCode != s.hashCode))
                return false;
        return regionMatches(0, s, 0, count);
    }
    return false;
}

Answer 5

I must confess enums are the last thing I would want to override equals() in.

I think the reason equals() is final in enums is that Java encourages == for enum comparison, and the implementation of equals() in enums simply uses it, So allowing equals() from being overridden is to prevent == and equals() from behaving differently, which is something other developers would not expect.

Answer 6

I am going the majority opinion. If the override of Enum::equals is forbidden, I don't think it was to follow the principle of least astonishment. I think it is to not break Java.

In the JVM, and in some old classes such like EnumMap, Enum identities may be coded internally with an int. For example, if we allow to override Enum::equals, then EnumMap<K, V> would break the contract of Map.