为什么Collections.checkedMap和朋友不常用？
我最近偶然发现了Javadoc的Collection.checkedMap系列函数，用于创建标准集合类型的动态类型安全视图。 考虑到他们在诊断相对常见的程序员错误的集合之上添加了另一层安全性，我认为它们会更受欢迎。 但是出于某种原因，在我参与过的所有大型Java项目中，我都没有看到它们被使用过一次。
我的问题是：Java程序员是否有更频繁地使用这些检查包装器的特殊原因？ 或者只是缺乏利益/缺乏对其存在的了解？
编辑 ：为了澄清我的问题，集合的通用版本仍然包含类型不安全的function。 Map的containsKey ， containsValue ， remove和get都可以对Object进行操作。 我的主要问题是，鉴于此类型 – 不安全，为什么更多人不使用已检查的实现来诊断运行时类型违规。
只有在滥用（或不使用）generics的情况下，才真正需要这些类。 它在运行时检查时重复，这应该足以在编译时通过generics引擎的类型安全保证执行。
因此，在不信任库用户的API设计者的上下文中使用这些方法只是非常有趣，并且希望保护自己或用户不正确地使用地图的用户。
以下是它的缺点：如果您的代码编译时没有原始类型警告或任何未经检查的转换/类型警告，则可以保证 checked*方法不会给您带来任何好处; 它们只是运行时命中。
编辑
你似乎总结说，因为remove ， get等操作一个Object ，它们在某种程度上是类型不安全的。 他们不是。 这些方法都不会将其操作数存储在地图中，因此您肯定不会损害地图本身的类型安全性。 这些方法采用Object主要有一个原因：为了向后兼容。 从来没有任何严格的要求要求坚持同一个class级。 例如，如果类A的实例和类B的实例可能在某种程度上彼此相等，则将a放入映射然后调用remove(b) 应该删除映射。
添加generics后，需要支持此行为以保持向后兼容性。 因此，他们无法将接口更新为remove(K)类的东西，因为现有代码可能依赖于能够在给定完全不同类的实例的情况下移除映射。 然而，它不是类型不安全的，并且使用已检查版本的地图不会稍微改变这种行为。
撤回：以下观点是错误的。 除了向后兼容性之外，还有一些很好的理由，为什么最好将查找索引设置为任何类型。
没有神圣的理由为什么这些方法必须采用Object而不是E 在真实世界的程序中，如果传递非E对象，那几乎肯定是一个应用程序错误。 在大多数情况下，E版API将优于Object版本。 而且我说Sun在这里犯了一个错误。 没有向后兼容性问题，因为通用API是一个全新的API。
幸运的是，如果我将非E类型传递给这些方法，我的IDE（IntelliJ）会警告我。 静态检查已超出语言规范所述和编译器的作用。