Java 集合的hashCode和equals.unmodifiableCollection（）

Collections

类有许多静态帮助器方法来提供各种集合类型的只读视图，例如

unmodifiableSet（）

，

unmodifiableList（）

，等等。对于这些视图对象，

hashCode（）

和

equals（）

方法将调用转发到基础集合。。。只有一个例外：

unmodifiableCollection（）

JavaDoc：

返回的集合不会将hashCode和equals操作传递给支持集合，而是依赖于

对象的
equals
和
hashCode
方法。如果支持集合是集合或列表，则有必要保留这些操作的契约

我的问题：这是在谈论wtf吗？？如果备份集合是一个集合或列表，我希望行为与
unmodifiableSet（）
和
unmodifiableList（）
一致。这将如何违反hashCode/equals契约？
来自JavaDoc for Collection：

Object.equals方法的通用契约声明
必须是对称的（换句话说，a等于（b）当且仅当
b、 等于（a））。List.equals和Set.equals的合同声明
列表仅等于其他列表，而集合则等于其他集合。因此
对于既不实现也不实现的集合类，自定义equals方法
当创建此集合时，List或Set接口必须返回false
与任何列表或集合相比。（按照同样的逻辑，不可能
编写一个正确实现集合和列表的类
接口。）

不可修改列表
是一个
不可修改的集合
，但反过来也不一样——包装
列表
的
不可修改集合
不是一个
不可修改列表
。因此，如果将包装列表
a
的
UnmodifiableCollection
与包装相同列表
a
的
UnmodifiableList
进行比较，这两个包装不应该相等。如果您只是传递到包装列表，它们将是相等的。
一个想法是不可修改的集合可以检查另一个的类型——如果它是集合而不是列表或集合，我不认为允许比较有什么害处。这将允许UnmodifiableCollection与其他UnmodifiableCollection以及其他一些案例进行有效比较。神秘的是，无法进行比较的是一个令人讨厌的角落陷阱&这将使“角落”变得更小，同时仍然保持对称性。