哪些 Java 设计明确地支持向后兼容性？ [关闭]答案

【问题标题】：What Java designs are explicitly done to support backwards compatability? [closed]哪些 Java 设计明确地支持向后兼容性？ [关闭]
【发布时间】：2009-06-07 14:36:20
【问题描述】：

由于this question 重新以四票结束，我再次尝试提出一个更狭隘的问题，希望社区能更积极地看待这个问题。

Java 中的哪些特定设计决策被记录为以它们的方式完成，不是因为这是首选的设计决策，而是因为有必要支持向后兼容性。

最明显的情况是泛型，您无法在运行时检测到类型参数。（所以你不能这样做：

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

语言设计和标准 API 中还有哪些此类示例？

【问题讨论】：

标签： java backwards-compatibility

【解决方案1】：

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

我能想到的三个以向后兼容性为名做出妥协的特性（除了你已经提到的通用擦除）是新的 for 循环语法、可变参数和自动装箱。

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

可变参数和自动装箱都增加了歧义的可能性。例如，如果您将对象数组传递给接受Object... 的方法，这是否意味着该数组应该作为可变参数数组或可变参数数组的元素传递？如果有重载，这会变得更加复杂。自动装箱在重载方面也有类似的歧义问题。这两个问题的解决方案是制定一个规则，即在解析方法调用时，它们首先使用 1.5 之前的规则进行解析（即：没有自动装箱，Object... 被视为Object[]）。只有当 1.5 之前的规则无法解决方法调用时，才会考虑新的 1.5 规则。

【讨论】：

真的选择第三个是为了向后兼容作为唯一/主要原因吗？在我看来，即使没有考虑向后兼容性也是有道理的。
在从一开始就使用该语言的任何可变参数实现中，您都希望有一个单独的语法用于“分解此数组并将其元素作为可变参数中的参数传递”。（例如，python 中的 *args 调用符号，甚至是 lisp 中的 apply 函数）然而，他们不想在 Java 中这样做，因为他们希望能够“升级”现有的 API 函数以使用 varargs 而让所有旧的调用者（期望一个数组）仍然工作。

【解决方案2】：

标准库中有很多例子

java.awt.Color 具有大小写名称相同的常量
由于引入了 java.util.Calendar，java.util.Date 中所有已弃用的方法 - 真是一团糟！！
java.util.Enumeration 仍在使用 java.util.Iterator 可以替代它的地方
Swing 中接受向量作为参数但可能已添加对 java.util.Collection 的支持的类

【讨论】：

【解决方案3】：

另一个是现在多个版本不推荐使用的所有类和方法，但不会消失。最值得注意的是已弃用的各种 Thread 方法。

【讨论】：

当然是真的。我记得当他们让 System.getenv() 抛出异常而不是返回结果时 - 但他们将方法留在那里以实现向后兼容性！
Baring destroy 所有其他已弃用的 Thread 方法都有某些用途，包括。暂停/恢复和停止一直很有用，尽管强烈反对。

【解决方案4】：

Backward compatibility and generics

【讨论】：