为什么Map.get（Object key）不是（完全）泛型的原因是什么

什么是决定不具有的接口完全通用的get方法背后的原因java.util.Map<K, V>。

为了澄清问题，该方法的签名是

V get(Object key)

代替

V get(K key)

我想知道为什么（与相同remove, containsKey, containsValue）。

正如其他人所提到的，之类的原因get()不是通用的，因为您要检索的条目的键不必与您传递给的对象的类型相同get()；方法的规范仅要求它们相等。这从equals()方法如何将对象作为参数（而不仅仅是与对象相同的类型）中得出。

尽管通常已经equals()定义了许多类，以便其对象只能等于其自己的类的对象，但是在Java中有很多地方并非如此。例如，规范List.equals()指出两个List对象都是相同的，并且都是相同的内容，即使它们都是的不同实现，也是如此List。因此，回到这个问题的示例中，根据方法的规范，可以使用a 作为参数，并且Map<ArrayList, Something>我可以get()使用LinkedListas参数调用它，并且它应该检索具有相同内容的列表的键。如果get()是通用的并且限制了它的参数类型，那将是不可能的。

Google的一位出色的Java程序员Kevin Bourrillion 在不久前的一篇博客文章中（关于Set而不是Map）就此问题进行了准确的撰写。最相关的句子：

一致地，除非有必要防止集合损坏，否则Java Collections Framework（以及Google Collections Library）的方法从不限制其参数类型。

我不能完全确定我是否同意它是一个原则-例如，.NET似乎要求正确的密钥类型就可以了-但值得遵循博客文章中的推理。（提到.NET时，值得解释的是，.NET中不存在问题的部分原因是，.NET中存在更大的问题，而方差有限。）

合同表示如下：

更正式地讲，如果此映射包含从键k到值v的映射，使得（key == null？k == null： key.equals（k）），则此方法返回v；否则，返回v。否则返回null。（最多可以有一个这样的映射。）

（我的重点）

因此，成功的键查找取决于输入键对等式方法的实现。那不一定取决于k的类别。

这是Postel法则的应用， “对您的工作要保守，对别人接受的东西要开放。”

不论类型如何，都可以执行相等性检查。该equals方法在Object类上定义，并且可以接受任何Object参数。因此，对于密钥等效性以及基于密钥等效性的操作来说，接受任何Object类型。

映射返回键值时，通过使用type参数，它可以保存尽可能多的类型信息。

我认为“泛型教程”的这一部分解释了这种情况（我的重点是）：

“您需要确保通用API不受过度限制；它必须继续支持API的原始合同。再次考虑java.util.Collection中的一些示例。预通用API如下所示：

interface Collection { 
  public boolean containsAll(Collection c);
  ...
}

天真地夸大它的尝试是：

interface Collection<E> { 
  public boolean containsAll(Collection<E> c);
  ...
}

尽管这肯定是类型安全的，但它不符合API的原始合同。 containsAll（）方法可用于任何类型的传入集合。仅当传入集合实际上仅包含E实例时，它才会成功，但是：

• 传入集合的静态类型可能有所不同，可能是因为调用者不知道传入的集合的确切类型，或者可能是因为它是Collection <S>，其中S是E的子类型。
• 用其他类型的集合调用containsAll（）是完全合法的。该例程应该工作，并返回false。”

原因是遏制是由方法决定的equals，hashCode哪种方法Object都采用Object参数。这是Java标准库中的早期设计缺陷。再加上Java的类型系统中的限制，它迫使任何依赖于equals和hashCode的值接受Object。

在Java中具有类型安全的哈希表和相等性的唯一方法是避免 Object.equals与Object.hashCode和使用一个通用的替代品。为此，功能Java随附类型类：Hash<A>和Equal<A>。HashMap<K, V>提供了for的包装，该包装采用Hash<K>和Equal<K>的构造函数。这个类是get和contains因此采取的方法类型的通用说法K。

例：

HashMap<String, Integer> h =
  new HashMap<String, Integer>(Equal.stringEqual, Hash.stringHash);

h.add("one", 1);

h.get("one"); // All good

h.get(Integer.valueOf(1)); // Compiler error

兼容性。

在泛型可用之前，只有get（Object o）。

如果他们将这种方法更改为get（<K> o），可能会迫使对Java用户的大规模代码维护只是为了使工作代码再次编译。

他们本可以引入另一种方法，例如说get_checked（<K> o）并弃用旧的get（）方法，以便有一条更平缓的过渡路径。但是由于某种原因，这没有完成。（现在的情况是，您需要安装诸如findBugs之类的工具，以检查get（）参数与地图的声明键类型<K>之间的类型兼容性。）

我认为与.equals（）的语义有关的参数是虚假的。（从技术上讲，它们是正确的，但我仍然认为它们是虚假的。如果o1和o2没有任何共同的超类，那么在他的脑海中就不会有任何设计师可以使o1.equals（o2）为真。）

还有一个重要的原因，因为它破坏了Map，因此在技术上无法完成。

Java具有类似的多态通用构造<? extends SomeClass>。标记为此类引用可以指向使用签名的类型<AnySubclassOfSomeClass>。但是多态泛型使该引用变为只读。编译器仅允许您将泛型类型用作方法的返回类型（例如简单的getter），但会阻止使用泛型为参数的方法（例如普通的setter）。这意味着如果您编写Map<? extends KeyType, ValueType>，编译器将不允许您调用method get(<? extends KeyType>)，并且映射将无用。唯一的解决方案是使此方法不通用：get(Object)。

我想是向后兼容。Map（或HashMap）仍然需要支持get(Object)。

我看着这个，想着为什么他们要这样做。我不认为任何现有答案都可以解释为什么它们不能仅使新的通用接口仅接受密钥的正确类型。实际原因是，即使他们引入了泛型，他们也没有创建新接口。Map接口与旧的非通用Map相同，仅用作通用和非通用版本。这样，如果您有一个接受非泛型Map的方法，则可以将其传递给a Map<String, Customer>，它仍然可以工作。同时，获取合同接受对象，因此新接口也应支持该合同。

在我看来，他们应该添加一个新接口并在现有集合上都实现，但是他们决定支持兼容接口，即使这意味着对get方法进行更糟糕的设计。请注意，集合本身将与现有方法兼容，仅接口不兼容。

我们现在正在进行大型重构，并且缺少此强类型的get（）来检查我们是否没有丢失旧类型的某些get（）。

但是我发现了一种用于编译时间检查的解决方法/难看技巧：使用强类型的get，containsKey，remove ...创建Map接口，并将其放入项目的java.util包中。

您将因为仅使用错误的类型调用get（）而得到编译错误，...对于编译器而言，其他一切似乎都正常（至少在eclipse kepler内部）。

检查构建后不要忘记删除此接口，因为这不是运行时所需的。