爲了支持向後兼容性，明確設計了哪些Java設計？

由於this question已退回四票，所以我想再次提出一個更狹義的問題，希望社區能夠更有利地看待。爲了支持向後兼容性，明確設計了哪些Java設計？

Java中的哪些特定設計決策被記錄爲完成的方式不是因爲這是首選設計決策，而是因爲它需要支持向後兼容性。

明顯的例子是泛型，在運行時無法檢測類型參數。（所以你不能做的：

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

存在於語言的設計和標準的API

來源

2009-06-07 Yishai

其他什麼這樣的例子因爲這個問題沒有一個唯一正確的答案，我不知道？它會票價任何比你的另一個問題。

三個特點，我能想到的（除了一般的刪除，您已經提到），在向後兼容的名義作出的妥協是新的for循環語法，可變參數和自動裝箱。

The新的for循環語法可能應該已經讀取for (item in List)，但是這將需要使in成爲保留字。這會導致很多向後兼容性問題，其中最重要的是System.in將不得不重新命名。

變量和自動裝箱都增加了模糊性的可能性。例如，如果將一個對象數組傳遞給接受Object...的方法，那麼這是否意味着該數組應該作爲可變參數數組或可變參數數組的元素傳遞？如果有重載，這會變得更加複雜。自動裝箱在重載方面存在類似的模糊問題。對這兩個問題的解決方案是，在解決方法調用時，首先解決它們的前1.5條規則（即：不自動裝箱，並且Object...被視爲Object[]）。只有在方法調用無法用1.5之前的規則解決的情況下，纔會考慮新的1.5規則。

來源

2009-06-07 15:18:34

作爲唯一/主要原因，第三個選項是否真的選擇向後兼容？在我看來，即使沒有向後兼容性，它也是有意義的。 – 2009-06-07 15:46:42

在開始語言的可變參數的任何實現中，您希望有一個單獨的語法來「分解此數組並將其元素作爲可變參數中的參數傳遞」。（例如，* args在python中調用記法，甚至在lisp中調用函數）但是，他們不想在Java中執行此操作，因爲他們希望能夠「升級」現有的API函數以使用可變參數讓所有的老調用者（期望有一個陣列）仍然可以工作。 – 2009-06-07 19:22:51