Я только что столкнулся с проблемой, вызванной Javajava.awt.geom.Area#equals(Area) метод. Задача может быть упрощена до следующего модульного теста:

@org.junit.Test
public void testEquals() {
    java.awt.geom.Area a = new java.awt.geom.Area();
    java.awt.geom.Area b = new java.awt.geom.Area();
    assertTrue(a.equals(b)); // -> true

    java.lang.Object o = b;
    assertTrue(a.equals(o)); // -> false
}

После некоторой царапины и отладки я, наконец, увидел в источнике JDK, что подписьequals метод вArea выглядит так:

public boolean equals(Area other)

Обратите внимание, что это делаетне @Override нормальныйequals метод изObject, но вместо этого просто перегружает метод более конкретным типом. Таким образом, два вызова в приведенном выше примере в конечном итоге вызывают разные реализацииequals.

Поскольку это поведение присутствует с Java 1.2, я предполагаю, что это не считается ошибкой. Поэтому меня больше интересует выяснениеЗачем было принято решениене правильно переопределитьequals метод, но в то же время предоставить перегруженный вариант. (Еще один намек на то, что это было принято, - это отсутствие перезаписанногоhashCode() Метод.)

Мое единственное предположение было бы, что авторы боялись, что медленныйequals реализация для областей не подходит для сравнения равенства при размещенииAreaвSet,Map,так далее. datastructures. (В приведенном выше примере вы можете добавитьa кHashSet, и хотяb равноaзвонитcontains(b) не удастся.) Опять же, почему они не просто назвали сомнительный метод таким образом, который не противоречит такой фундаментальной концепции, какequals метод?