为什么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< Object，Object> ，而不是 Map< ; String，String> ？

So, why in Java 5 did they retrofit this class to implement Map<Object,Object> and not Map<String,String>?

javadoc 状态：

由于属性继承自Hashtable，put和putAll方法可以应用于Properties对象。强烈建议不要使用它们，因为它们允许调用者插入键或值不是字符串的条目。应该使用setProperty方法。如果存储或保存方法在包含非String键或值的受影响的Properties对象上调用，调用将失败。

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?

我想让属性实现 Map< String，String> 将不会完全向后兼容为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.

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

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.

大多数受过教育的观察者认为属性应该永远不会继承自 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的niggles恼人，看看它。

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屋！