この質問は 4 票で締め切られたので、コミュニティがより好意的に見てくれることを願って、より狭い質問をもう一度しようと思います。
Java における特定の設計上の決定のうち、どのような方法で文書化されているかは、それが好ましい設計上の決定だったからではなく、下位互換性をサポートするために必要だったからです。
明らかなケースは、実行時に型パラメーターを検出できない Generics です。（したがって、次のことはできません：
public void addEmptyMember(List<?> someList) {
if (someList instanceof List<String>) {
((List<String>) someList).add("");
}
}
言語設計と標準 API には他にどのような例がありますか?
標準ライブラリにはたくさんの例があります
この質問には 1 つの正解がないため、他の質問よりもうまくいくかどうかわかりません。
下位互換性の名目で妥協した (既に述べた一般的な消去に加えて) 考えられる 3 つの機能は、新しい for ループ構文、varargs、および autoboxing です。
新しい for ループ構文にはおそらく readが必要でしたが、そのためには予約語にするfor (item in List)必要がありました。inこれにより、多くの下位互換性の問題が発生し、名前のSystem.in変更が必要になるという事実が最も重要でした。
varargs と autoboxing は両方ともあいまいさの可能性を追加しました。たとえば、オブジェクトの配列を受け入れるメソッドに渡す場合、Object...その配列は vararg 配列または vararg 配列の要素として渡す必要があるということですか? オーバーロードがある場合、これはさらに複雑になります。オートボクシングには、オーバーロードに関する同様のあいまいさの問題があります。これらの問題の両方に対する解決策は、メソッド呼び出しを解決するときに、最初に 1.5 より前のルールで解決されるというルールにすることでした (つまり、オートボクシングなしで、Object...として扱われますObject[])。メソッド呼び出しが 1.5 より前のルールで解決できない場合にのみ、新しい 1.5 ルールが考慮されます。
もう 1 つは、現在複数のバージョンで非推奨になっているすべてのクラスとメソッドですが、なくなることはありません。最も注目すべきは、推奨されていないさまざまな Thread メソッドです。