Хеш-код разных объектов одинаковый

Два неравных объекта могут иметь один и тот же хэш-код. Фактически, это было разрешено математическим требованием. Подумайте, например, о строках: существует бесконечно много неравных строк («a», «aa», «aaa» ...), но только 2 ^ 32 возможных значения int. Очевидно, что должны быть разные строки, которые имеют общий хэш-код.

Но HashSet знает об этом, поэтому он использует результат equals, а также хэш-код. Если добавляется только один из объектов, то у них не просто один и тот же хэш-код - они равны, как это возвращает метод equals. Мы не можем определить, почему это так, не говоря уже о том, преднамеренно ли это, без кода настраиваемого класса.

договор на объект говорит, что одинаковые объекты должны иметь одинаковый хэш-код. Но обратное неверно: объекты с одинаковым хэш-кодом не обязательно должны быть равны. В Javadocs прямо говорится об этом:

• It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.

Если в документации класса явно не указано, как он вычисляет свой хэш-код, вам, вероятно, не следует рассматривать это как установленный контакт, и вы должны ожидать, что он может измениться между версиями.

Очевидно, что что-то изменилось в базовом классе, и вам просто нужно будет найти это и исправить, иначе реализовать hashCode() и equals() в этом классе приемлемо.

Кто-то где-то реализовал hashCode() для возврата 1, что является идиотизмом. Лучше было бы вообще этого не реализовывать. И найти это несложно. Просто посмотрите Javadoc для CustomObject и посмотрите, откуда он унаследован от hashCode().

Проблема здесь в реализации класса CustomObject (или одного из его предков). Автор CustomObject (или один из его предков) неправильно переопределил методы toString, hashCode и equals, не понимая их семантики и последствий. Вот ваши варианты (не обязательно в указанном порядке) для решения проблемы:

1. Вы должны уведомить автора вашей библиотеки зависимостей о проблеме в классе CustomObject и правильно реализовать или переопределить методы toString, hashCode и equals. Но помните - автор кода зависимости может снова вернуть вас в это место в будущем.
2. Предполагая, что класс CustomObject не является final - расширьте CustomObject (обратите внимание - его лучше называть как CustomClass, а не CustomObject), чтобы иметь правильную реализацию методов toString, hashCode и equals. Используйте этот расширенный класс в своем коде вместо класса CustomObject. Это даст вам лучший контроль, потому что ваш код зависимости не может снова вызвать эту проблему.
3. Используйте AOP, чтобы ввести переопределенную и правильную реализацию методов toString, hashCode и equals в классе CustomObject. Этот подход также является перспективным, как и вариант 2 выше.

Я думаю, вы уже поняли, каков ответ на ваш вопрос, но код, который вы добавили в своем обновлении, дает понять:

1. Ваш CustomClass расширяет BaseClass.

2. BaseClass заменяет Object::hashCode()

3. Переопределение в версии BaseClass, которую вы нам показали всегда будет возвращать 1. Он вызывает метод hashCode(ObjectLocator, HashCodeStrategy2) с определенной стратегией, но реализация этого метода просто игнорирует аргумент стратегии.

Теперь довольно ясно, что эта версия кода BaseClass может возвращать только 1 в качестве хэш-кода. Но вы говорите, что ваш код работал, а вы только изменили зависимость. Из этого мы должны сделать вывод, что зависимость изменилась, и что новая версия зависимости сломана.

Если в этом есть что-то «странное», так это то, что кто-то решил реализовать (новый) BaseClass таким образом и выпустить его, не тестируя должным образом.

На самом деле, есть возможный способ заставить ваш CustomClass работать. Метод BaseClass::hashCode(ObjectLocator, HashCodeStrategy2) является общедоступным, а не окончательным, поэтому вы можете переопределить его на своем CustomClass следующим образом :.

@Override
public int hashCode(ObjectLocator locator, HashCodeStrategy2 strategy) {
    return System.identityHashCode(this);
}

И действительно, возможно, разработчики BaseClass намереваются сделать это. Но все же я бы сказал, что BaseClass сломан:

• Кодирование класса так, чтобы hashCode возвращал 1, поскольку поведение по умолчанию является неприятным.
• В BaseClass нет документации javadoc, объясняющей необходимость переопределения метода.
• Их (необъявленное?) Изменение поведения BaseClass - это изменение Нарушение API. Вы не должны делать такие вещи без уважительной причины и без предупреждения.
• Поведение по умолчанию соответствующего метода equals объективно неверно.