我最近偶然发现了Javadoc Collection.checkedMap系列函数,用于创建标准集合类型的动态类型安全视图.考虑到他们在诊断相对常见的程序员错误的集合之上添加了另一层安全性,我认为它们会更受欢迎.但是出于某种原因,在我所做的所有大型Java项目中,我都没有看到它们被使用过一次.
我的问题是:Java程序员是否有更频繁地使用这些检查包装器的特殊原因？或者只是缺乏利益/缺乏对其存在的了解？
编辑:为了澄清我的问题,集合的通用版本仍然包含类型不安全的功能. Map的containsKey,containsValue,remove,和get所有的操作上Object,例如.我的主要问题是,鉴于此类型 - 不安全,为什么更多人不使用已检查的实现来诊断运行时类型违规.
Mar*_*ers 15
只有在滥用(或不使用)泛型时,这些类才真正必要.它在运行时检查时重复,这些检查应该足以在编译时通过泛型引擎的类型安全保证执行.
因此,在不信任库用户的API设计人员的上下文中使用这些方法只是非常有趣,并且希望保护自己或用户不正确地使用地图的用户.
这是它的缺点:如果您的代码编译时没有原始类型警告或任何未经检查的转换/类型警告,您可以保证这些checked*方法不会给您任何好处; 它们只是运行时命中.
编辑
你似乎总结说,因为remove,get等操作一个Object,它们在某种程度上是类型不安全的.他们不是.这些方法都不会将其操作数存储在地图中,因此您肯定不会损害地图本身的类型安全性.这些方法使用Object的一个主要原因是:为了向后兼容.从来没有任何严格的要求,要求坚持同一个班级.例如,如果类A的实例和类B的实例可能在某种程度上彼此相等,则放入a映射然后调用remove(b) 应该删除a映射.
添加泛型后,需要支持此行为以保持向后兼容性.因此,他们无法将界面更新为类似remove(K)现有代码可能依赖于在给定完全不同类的实例的情况下移除映射的情况.然而,它不是类型不安全的,并且使用已检查的地图版本不会稍微改变这种行为.