代码之家 › 专栏 › 技术社区 › Yishai

Java设计是如何明确支持向后兼容性的?[关闭]

backwards-compatibility java

6

Yishai · 技术社区 · 17 年前

自从 this question 回到四票结束时,我再次尝试问一个更窄的问题,希望社区能更友好地看待这个问题。

Java中的特定设计决策被记录为它们不是这样做的,因为这是首选的设计决策,而是因为有必要支持向后兼容性。

很明显的情况是泛型,在运行时无法检测类型参数。(所以你不能这样做:

 public void addEmptyMember(List<?> someList) {
      if (someList instanceof List<String>) {
            ((List<String>) someList).add("");
      }
 }

在语言设计和标准API中还有什么其他的例子?

4 回复 | 直到 13 年前

1

3

Laurence Gonsalves 17 年前

因为这个问题没有一个正确的答案,我不确定它是否会比你的另一个问题更好。

我能想到的三个特性(除了您已经提到的一般擦除之外)以向后兼容性的名义做出了让步,它们是新的for循环语法、varargs和autoboxing。

新的for循环语法可能应该 for (item in List) 但是那需要 in 变成一个保留字。这将导致许多向后兼容性问题,尤其是 System.in 必须重新命名。

varargs和autoboxing都增加了歧义的可能性。例如,如果将对象数组传递给接受 Object... 这是否意味着数组应该作为vararg数组或vararg数组的元素传递?如果存在重载,这会变得更加复杂。自动氧化与过载有类似的模糊性问题。解决这两个问题的方法是使其成为一个规则,即在解决方法调用时,首先使用1.5之前的规则(即:不自动氧化,以及 对象… 被视为 Object[] )只有当方法调用不能用1.5之前的规则解决时,才会考虑新的1.5规则。

2

3

Mark 17 年前

标准库中有很多示例

java.awt.color与大小写名称具有相同的常量
由于java.util.calendar的引入,java.util.date中所有不推荐使用的方法都变得一团糟!!
java.util.Enumeration仍在使用中,java.util.Iterator可以替换它
swing中接受向量作为参数,但可能已经为java.util.collection添加了支持的类

3

2

Jens Schauder 17 年前

另一种方法是所有的类和方法,这些类和方法现在已经在多个版本中被弃用了,但不会消失。最值得注意的是不推荐使用的各种线程方法。

4

1

lisak 13 年前

Backward compatibility and generics