arrtКогда-то перед до мной был такой вопрос - что будет если в обьектов функция hashcode() будет возвращать одинаковое значение, например 1?
HashMap из таких объектов будет работать крайне не эффективно, из-за постоянных коллизий.

arrtС прочитаного здесь я понял что все обьекты, например в hаshmаp, будут возвращать в методе еquаls() truе и будут считатся одинаковыми?
Не будет equals() возвращать true. Прочитайте внимательно не только эту ветку, но и JavaDoc класса java.lang.Object.

arrtРаньше думал что в эквале нету зависимости от хешкод, в этой теме она представлена.
Зависимость есть. Но она совсем не такая как вы решили.

arrtЭто обязательная зависимость?
Как бы, обязательная по документации. Но к очевидным ошибкам в runtime или compile-time отсутсвие этой зависимости не приводит.

arrtТо есть будут постоянные колизии и что? Хешмап будет неправильно работать или система будет очень долго разрешать эти колизии?
Производительность выборки из HashMap будет хуже чем полный перебор по массиву. Вся польза от структуры HashMap нивелируется.

arrtЕсли все таки в большинстве случаев есть зависимость иквала от хешмап почему не будет возвращать truе - как тогда система будет "бороться" с этой несправедливостью и какой механизм вместо сравнение хешкодов приведет к решению проблемы колизий.

Какой-то набор слов. Какая ещё несправедливость? Кто должен true возвращать?

arrtВот действительно раньше думал что иквал() сравнивает типы обьектов, потом их все поля, а функция хешкод -- есть лиш быстрой альтернативой более громзкого первого метода.
Assumption is the mother of all fuck ups. Не нужно выдумывать то что написано в документации.

arrtИ я читал джава документацию - там о какой то ссылке на адрес обьекта в памяти речь идет -- а задали мне вопрос на засыпку и делай что хочеш если этот "адрес" будет 1?
Вы путаете причину и следствие. То что java.lang.Object.hashCode() реализован определенным образом совершенно не значит что вашим объектам подойдёт такая реализация.

arrtХотя снова таки функция на практике как и написано в документации нужна в хешмапе и хешсете.
HashSet это обертка над HashMap.

arrtА какая дефолтная реализация двух методов для класа Objеct так не понял.

arrtДефолтную реализацию иквала() привели, а хешкода нет.
Она зависит от настроект и реализации JVM. Я могу найти его в исходниках OpenJDK. Но она вам вообще никак не поможет. Вам бы понимания.

arrtХотя если сравниваются ссылки то это тот же заувулированый хешкод с адресом.
Ну, как бы, да.

arrtА мое представление о сравнение типа и полей вообще ни к чему не годится ибо однаковых обьектов можно создать сколь угодно.

Сложно комментировать. Что у вас за представление - не знаю.

arrt Но как тогда реализировать эти методы к хешсету, вот здесь именно не надо дубликатов.
Кому реализаовать? Вам? Есть куча статей по этому поводу. Есть генераторы в IDE и есть библотеки, которые помогают автоматизировать реализацию этих методов.

arrt
Аналогично к хешмапу - с включением хешкода в иквал?

Вы кажется пропустили мой предыдущий коментарий если до сих пор их разделяете.
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashSet.java

arrt Или мой подход как раз подойдет ибо если обьекты одного типа имеют те же поля значит это дубликат - и снова добавлять в колекцию нельзя?
Вы немного путаетесь в терминологии.
1. Поля о объектов одного типа - одни и те же. Так как поля определяются классом, то есть типом. Вы хотели написать "значение полей", но не написали.
2. Да, зачастую, вычисление hashCode и equals() основано на полях класса. Но нужно аккуратно выбирать на каких именно полях класса. Потому что для mutable объектов, изменение значение поля может привести к изменению значения hashCode, что фатально для HashMap. Поэтому если у вас все поля объекта изменяемые, то, возможно, есть смысл оставить дефолтную реализацию.

arrtBlazkowicz, А как ситуация состоит в .nеt касательно методов (get)hashcode(), equals()?
https://msdn.microsoft.com/en-us/library/system.object(v=vs.110).aspx