Acabei de encontrar um problema causado pelo Javajava.awt.geom.Area#equals(Area) método. O problema pode ser simplificado para o seguinte teste de unidade:

@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
}

Depois de alguns arranhões e depurações, finalmente vi na fonte JDK que a assinatura doequals método emArea se parece com isso:

public boolean equals(Area other)

Note que simnão @Override o normalequals método deObject, mas sobrecarrega o método com um tipo mais concreto. Assim, as duas chamadas no exemplo acima acabam chamando implementações diferentes deequals.

Como esse comportamento está presente desde o Java 1.2, presumo que não seja considerado um bug. Estou, portanto, mais interessado em descobrirporque a decisão foi tomada paranão substituir corretamente oequals , mas ao mesmo tempo forneça uma variante sobrecarregada. (Outra dica de que essa foi uma decisão real tomada é a ausência de uma substituiçãohashCode() método.)

Meu único palpite seria que os autores temiam que a lentaequals implementação para áreas é inadequada para comparar a igualdade ao colocarAreapecadoSet,Mapetc. estruturas de dados. (No exemplo acima, você pode adicionara para umHashSet, e emborab é igual aachamandocontains(b) falhará.) Então, novamente, por que eles não nomearam o método questionável de uma maneira que não se choca com um conceito tão fundamental quantoequals método?