java.util.Properties为什么要实现Map<Object,Object>?而不是 Map<String,String> [英] Why does java.util.Properties implement Map<Object,Object> and not Map<String,String>
问题描述
java.util.Properties 类用于表示键和值都是字符串的映射.这是因为 Properties 对象用于读取 .properties 文件，这些文件是文本文件.
The java.util.Properties class is meant to represent a map where the keys and values are both Strings. This is because Properties objects are used to read .properties files, which are text files.
那么，为什么在 Java 5 中他们改造这个类来实现 Map 而不是 Map?
So, why in Java 5 did they retrofit this class to implement Map<Object,Object> and not Map<String,String>?
javadoc 指出:
因为 Properties 继承自 Hashtable，所以 put 和 putAll 方法可以应用于 Properties 对象.强烈建议不要使用它们，因为它们允许调用者插入键或值不是字符串的条目.应改用 setProperty 方法.如果在包含非字符串键或值的受损"属性对象上调用 store 或 save 方法，调用将失败.
Because Properties inherits from Hashtable, the put and putAll methods can be applied to a Properties object. Their use is strongly discouraged as they allow the caller to insert entries whose keys or values are not Strings. The setProperty method should be used instead. If the store or save method is called on a "compromised" Properties object that contains a non-String key or value, the call will fail.
既然键和值都应该是字符串，那么为什么不通过使用适当的泛型类型来静态强制呢?
Since the keys and values are both supposed to be Strings then why not enforce that statically by using the proper generic type?
我猜让 Properties 实现 Map 不会完全向后兼容为 Java 5 之前编写的代码.如果你有旧代码将非字符串转换为 Properties 对象，那么该代码将不再使用 Java 5 进行编译.但是......这不是一件好事吗?泛型的全部意义不是在编译时捕获此类类型错误吗?
I guess making Properties implement Map<String,String> would not be fully backward compatible with code written for pre-Java 5. If you have older code that sticks non-strings into a Properties object then that code would no longer compile with Java 5. But... isn't that a good thing? Isn't the whole point of generics to catch such type errors at compile time?
推荐答案
因为他们在 Java 的早期就匆匆忙忙地做了，并没有意识到四个版本之后会有什么影响.
Because they did it in a hurry in the early days of Java, and didn't realise what the implications would be four versions later.
从一开始，泛型就应该是 Java 设计的一部分，但由于过于复杂，而且在当时没有必要，因此放弃了该功能.因此，标准库中的许多代码都是在假设非泛型集合的情况下编写的.它采用了 Martin Odersky 的原型语言Pizza"来展示如何在保持近乎完美的向后兼容性的同时，对 Java 代码和字节码进行很好的处理.该原型催生了 Java 5，其中集合类通过泛型进行了改造，允许旧代码继续工作.
Generics were supposed to be part of the design of Java from the beginning, but the feature was dropped as being too complicated and, at the time, unnecessary. As a result, lots of code in the standard libraries is written with the assumption of non-generic collections. It took the prototype language "Pizza" from Martin Odersky to show how they could be done fairly well while maintaining near perfect backwards compatibility, with both Java code and bytecode. The prototype led to Java 5, in which the collections classes were retrofitted with generics in a way that allowed old code to keep working.
不幸的是，如果他们追溯让 Properties 继承自 Map，那么以下以前有效的代码将停止工作:
Unfortunately, if they were to retroactively make Properties inherit from Map<String, String>, then the following previously valid code would stop working:
Map<Object, Object> x = new Properties()
x.put("flag", true)
我无法理解为什么有人会这样做，但 Sun 对 Java 向后兼容性的承诺已经超出了英雄的意义.
Why anybody would do that is beyond me, but Sun's commitment to backwards compatibility in Java has gone beyond heroic into the pointless.
现在大多数受过教育的观察者赞赏的是，Properties 根本不应该从 Map 继承.相反，它应该环绕 Map，只暴露 Map 的那些有意义的特性.
What's now appreciated by most educated observers is that Properties should never have inherited from Map at all. It should instead wrap around Map, exposing only those features of Map that make sense.
自从重新发明 Java 以来，Martin Odersky 继续创建了新的 Scala 语言，该语言更简洁，继承的错误更少，并在许多领域开辟了新天地.如果您发现 Java 的小问题很烦人，请看一看.
Since reinventing Java, Martin Odersky has gone on to create the new Scala language, which is cleaner, inherits fewer mistakes, and breaks new ground in a number of areas. If you're finding Java's niggles annoying, take a look at it.
这篇关于java.util.Properties为什么要实现Map<Object,Object>?而不是 Map<String,String>的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
