为何java.util.Properties继承Hashtable<Object,Object>而非Hashtable<String,String>？

这个问题得结合Java的API设计历史和向后兼容性来理解，咱们一步步拆解：

1. 历史遗留+向后兼容的硬要求 #

Properties类早在JDK 1.0就诞生了，而泛型是JDK 5才加入的特性。在泛型出现之前，Hashtable本身就是无类型限制的——所有键值对都按Object处理。当JDK 5引入泛型时，Java团队不能直接把Properties的父类改成Hashtable<String, String>，因为大量老代码可能已经在使用Properties继承自Hashtable的put(Object, Object)等方法操作非String类型的键值对，强行修改泛型会导致这些老代码直接编译失败，这严重违反了Java一直坚持的向后兼容原则。

2. 类型安全封装与底层操作的妥协 #

你提到的setProperty(String key, String value)和getProperty(String key)其实是Properties为普通用户提供的类型安全的便捷入口，它们把操作限定在String类型内，完全符合配置属性的使用场景。但Properties并没有禁用父类Hashtable的原生方法（比如put(Object, Object)），这看起来矛盾，实则是为了兼顾：

• 给大多数用户提供符合预期的String类型操作
• 保留对依赖Hashtable原生方法的老代码的兼容性

不过要注意，Java官方其实是不推荐直接用Hashtable的put方法操作Properties的——如果存入非String类型的键值，后续用getProperty读取时会触发ClassCastException，因为getProperty会默认把结果强转为String。

3. 泛型继承的局限性 #

就算在泛型时代，Java的泛型也存在协变/逆变的限制。如果Properties继承Hashtable<String, String>，那它就无法被当作Hashtable<Object, Object>传入那些老的API方法中，这会彻底打破原有代码的调用逻辑，显然是不可行的。

这类无类型限定的集合在特定场景下有用，但使用时要特别留意以下几点：

• 类型转换风险极高：每次取元素都要手动强转，一旦存入的元素类型不符合预期，运行时就会抛出ClassCastException，而且这类错误编译期根本检测不出来，排查起来很麻烦。
• 代码可读性差：其他开发者看到<Object, Object>的集合，完全没法直观知道里面存的是什么类型的数据，后续维护成本会很高。
• 优先用具体泛型参数：除非你确实需要存储多种不同类型的对象，否则一定要尽量指定具体的泛型（比如HashMap<String, Integer>），这样编译期就能帮你做类型检查，代码也更清晰。
• 区分线程安全需求：Hashtable是线程安全的，但性能较差；HashMap是非线程安全的，性能更好。如果需要线程安全的集合，现在更推荐用ConcurrentHashMap，它的锁粒度更细，性能比Hashtable好很多。
• 警惕类型擦除问题：Java泛型是基于类型擦除实现的，<Object, Object>集合会丢失所有类型信息，如果你的逻辑需要依赖元素类型做判断，很容易出现意料之外的问题。

内容的提问来源于stack exchange，提问作者Nikolas