Какие проекты Java явно выполнены для поддержки обратной совместимости?[закрыто]

Question

С тех пор как этот вопрос возвращаясь к четырем голосам за закрытие, я снова пытаюсь задать более узкий вопрос, который, надеюсь, сообщество воспримет более благосклонно.

Какие конкретные проектные решения в Java документированы так, чтобы они выполнялись так, как они есть, не потому, что это было предпочтительным проектным решением, а скорее потому, что это было необходимо для поддержки обратной совместимости.

Очевидный случай - это Generics, где вы не можете определить параметр type во время выполнения.(Таким образом, вы не можете сделать:

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

Какие еще подобные примеры существуют в языковом дизайне и стандартном API?

Answer 1

Поскольку на этот вопрос нет ни одного правильного ответа, я не уверен, что он будет лучше, чем ваш другой вопрос.

Три функции, о которых я могу вспомнить (в дополнение к общему стиранию, о котором вы уже упоминали), которые привели к компромиссам во имя обратной совместимости, были новым синтаксисом цикла for, varargs и автоматической упаковкой.

Новый синтаксис цикла for, вероятно, должен был гласить for (item in List), но для этого потребовалось бы сделать in в зарезервированное слово.Это вызвало бы многочисленные проблемы с обратной совместимостью, не последней из которых является тот факт, что System.in пришлось бы переименовать.

varargs и автобоксинг добавили возможности двусмысленности.Например, если вы передаете массив объектов методу, который принимает Object... означает ли это, что массив должен быть передан как массив vararg или как элемент массива vararg?Это становится еще сложнее, если возникают перегрузки.Автобоксинг имеет аналогичные проблемы с неоднозначностью при перегрузке.Решение обеих этих проблем состояло в том, чтобы установить правило, согласно которому при разрешении вызовов методов они сначала разрешаются с помощью правил, существовавших до версии 1.5 (т.е.:никакой автоматической упаковки, и Object... рассматривается как Object[]).Новые правила 1.5 рассматриваются только в том случае, если вызов метода не может быть разрешен с помощью правил, существовавших до версии 1.5.

Answer 2

В стандартной библиотеке есть множество примеров

• java.awt.Color имеет одинаковые константы с именами в верхнем и нижнем регистре
• Все устаревшие методы в java.util.Дата с учетом внедрения java.util.Календарь - какой беспорядок!!
• java.util.Перечисление все еще используется там, где java.util.Итератор мог бы заменить его
• Классы в Swing, которые принимают векторы в качестве аргументов, но могли бы иметь добавленную поддержку для java.util.Коллекция

Answer 3

Другим вариантом были бы все классы и методы, которые к настоящему времени устарели для нескольких версий, но просто так никуда не денутся.Наиболее примечательными являются различные методы потоков, которые устарели.

Answer 4

Обратная совместимость и дженерики