Почему Sun указала реализацию String.hashCode ()?

Question

Кажется, что ведутся споры о том, можно ли полагаться на текущую реализацию String.hashCode(), потому что, технически говоря, это гарантировано спецификацией (Javadoc).

1. Почему Sun указала реализацию String.hashCode() в спецификации?
2. Зачем разработчикам полагаться на конкретную реализацию hashCode ()?
3. Почему Солнце так боится, что небо упадет, если String.hashCode() изменится в будущем? (Это, вероятно, объясняется # 2)

Answer 1

Причина полагаться на конкретную реализацию hashCode () может быть в том случае, если он когда-либо будет сохранен в базе данных, файле или любом другом носителе. Плохие вещи (tm) произойдет, если данные будут считаны обратно при изменении алгоритма хеширования. Вы можете столкнуться с неожиданными коллизиями хэша и, что еще более тревожно, с невозможностью найти что-либо по его хэшу, поскольку хэш изменился между сохраняющимися данными и «сейчас».

На самом деле, это в значительной степени объясняет и пункт № 3 =)

Причиной для пункта № 1 может быть «разрешение взаимодействия». Если реализация hashCode заблокирована, данные могут быть безопасно разделены между различными реализациями Java. т.е. хеш данного объекта всегда будет одинаковым независимо от реализации.

Answer 2

Реализация изменила с исходного класса String. Если я помню, раньше было так, что только каждый шестнадцатый (?) Символ использовался в хэше для "длинных" строк.

Возможно, он был задан для обеспечения совместимости сериализации между последующими версиями Java или даже между средами выполнения различных поставщиков. Я согласен, программист не должен полагаться на конкретную реализацию hashCode() напрямую, но ее изменение может потенциально сломать много сериализованных коллекций.