为什么 java.util.Properties 实现 Map 而不是 Map

The java.util.Properties类旨在表示一个映射，其中键和值都是字符串。这是因为Properties对象用于读取.properties文件，它们是文本文件。

那么，为什么在Java 5中他们要改造这个类来实现Map<Object,Object>并不是Map<String,String>?

The javadoc http://java.sun.com/j2se/1.5.0/docs/api/ states:

由于 Properties 继承自 Hashtable，因此 put 和 putAll 方法可以应用于 Properties 对象。强烈建议不要使用它们，因为它们允许调用者插入键或值不是字符串的条目。应改用 setProperty 方法。如果对包含非 String 键或值的“受损”Properties 对象调用 store 或 save 方法，则调用将失败。

既然键和值都应该是字符串，那么为什么不使用正确的泛型类型静态地强制执行呢？

我猜制作Properties实施Map<String,String>不会与为 Java 5 之前版本编写的代码完全向后兼容。如果您有将非字符串粘贴到 Properties 对象中的旧代码，那么该代码将不再使用 Java 5 进行编译。但是......这不是一个好主意吗？事物？泛型的全部意义不就是在编译时捕获此类类型错误吗？

因为他们在Java早期做的很匆忙，并没有意识到四个版本之后会带来什么影响。

泛型从一开始就被认为是 Java 设计的一部分，但由于过于复杂且在当时没有必要而放弃了该功能。因此，标准库中的许多代码都是在假设非泛型集合的情况下编写的。 Martin Odersky 的原型语言“Pizza”展示了如何在保持与 Java 代码和字节码近乎完美的向后兼容性的同时做得相当好。该原型催生了 Java 5，其中集合类使用泛型进行了改造，从而允许旧代码继续工作。

不幸的是，如果他们追溯Properties继承自Map<String, String>，那么以下先前有效的代码将停止工作：

Map<Object, Object> x = new Properties()
x.put("flag", true)

我不明白为什么有人会这样做，但 Sun 对 Java 向后兼容性的承诺已经超出了英雄的范畴，变得毫无意义。

现在大多数受过教育的观察家所赞赏的是Properties永远不应该继承自Map根本不。它应该环绕Map，仅公开 Map 中那些有意义的特征。

自从重新发明了 Java 以来，Martin Odersky 继续创建了新的 Scala 语言，它更干净，继承的错误更少，并在许多领域开辟了新天地。如果您觉得 Java 的问题很烦人，请看一下它。