java - 为什么hashCode()在Object而不是单独的接口？

首先,我想说明我已经知道了javadoc,java.lang.Object.hashCode()因此没有必要再次提及它.

我要问的是:为什么不java.lang.Object.hashCode()进入一个名为(可能)的单独界面Hashable？像`java.lang.Comparator'？

对我来说,hashCode()仅用于与哈希相关的数据结构中,HashMap或者HashTablea)a)未在每个应用程序中使用b)通常与极少数类型的键一起使用,例如String或Integer不与InputStream(或类似的东西).

我知道我不需要hashCode()为我的每一个类实现,但是,在某种程度上不是以牺牲性能为代价向类添加方法？特别是对于java.lang.ObjectJava中每个类的超类.

即使在JVM中进行了特殊优化以便可以忽略性能损失,我仍然认为为每个人Object提供一个根本不经常实现的行为是不明智的.根据接口隔离原则:

不应该强迫任何客户端依赖它不使用的方法.

我在网上做了一些搜索,我能找到的唯一相关页面就是这个.

第一个答案表达(部分)与我的想法相同,其他一些人试图回答这个问题,主要是说" hashCode()每个人都Object可以存储任何类型的物体HashMap",我认为这并不令人满意.

我在这里提出了我自己的解决方案,它既满足了接口隔离原则,又能够在HashMap不增加整个系统复杂性的情况下存储任何内容:

hashCode()从中移除java.lang.Object.
让一个接口Hashable,包含hashCode()与前者相同的合同java.lang.Object.hashCode().
让一个HashProvider带有类型参数的接口T包含provideHashCode(T t)为对象提供哈希码.(想想Comparator<T>).
让我们有一个HashProvider<Object>被调用的实现,DefaultHashProvider它为Object使用当前实现的任何一个生成哈希码Object.hashCode().(对于Java 8,Object.hashCode()是一个本机方法,我期望DefaultHashProvider.provideHashCode()为任何方法返回相同的东西Object)
修改的构造HashMap和HashTable使一切都可以通过存储在其中:
1. 使用provideHashCode()if a HashProvider指定.
2. 使用hashCode()if的底层元素实现Hashable.
3. DefaultHashProvider否则使用.

我相信这在实践中是可行的,因为它只是系统的一种变体Comparable,Comparator而且TreeMap.

让我重复我的问题:

考虑到Java开发团队不应该提出类似于我的解决方案,有没有充分的理由不这样做？我目前还没有意识到一些高级考虑因素吗？我有以下假设,他们中的任何一个都接近正确的答案吗？

此解决方案所需的某些语言功能(如泛型类型)仅在Java开头之后才能使用 - 从1.5开始.但是,我认为Comparator,Comparable连同TreeMap从1.2开始存在,无法用技术来存储它们适应HashMap？
hashCode()在JVM中的某个地方使用,因此它需要每个Object都有一个哈希码.但是,DefaultHashProvider.provideHashCode()对于非合并者,也可以使用(或其本机实现).