Почему Java утверждает, что версия 1.5 должна быть обратно совместима?

Рассмотрим программу на Java, которая была написана для использования типов коллекций Java до версии Java 1.5.

До Java 1.5 я бы написал

 List l = new ArrayList();
 l.append("Hello");
 l.append("World");
 String hello = (String) l.get(0);

Теперь с моделью стирания типов я могу скомпилировать этот код в Java 1.5 или более поздней версии... даже без предупреждения компилятора. Но я также могу использовать те же самые классы коллекций современным способом; например

 List<String> l = new ArrayList<>();
 l.append("Hello");
 l.append("World");
 String hello = l.get(0);

Обратите внимание, что в обоих примерах я использую одни и те же классы и интерфейсы.

Без модели стирания, чтобы замазать трещины, разработчикам Java пришлось бы создавать параллельный набор классов и интерфейсов для коллекций; то есть

• Коллекции Pre-1.5 без дженериков и параметров типа
• Коллекции после версии 1.5 с дженериками и параметрами типа

Поскольку эквивалентность типов Java основана на именах/идентификаторах типов, а не на эквивалентности на основе подписи (или утиной типизации), эти две иерархии коллекций будут несовместимы. Это означает, что API и реализации, использующие коллекции, должны будут использовать выберите между коллекциями до версии 1.5 и после версии 1.5. Смешивать их было бы неудобно... и неэффективно.

Конечный результат был бы большой проблемой для людей/организаций, которым нужно было использовать устаревшие библиотеки и приложения Java. По сути, переход на Java 1.5 означал бы много переписывания приложений, которые прекрасно работали. Это убило бы дженерики и Java как корпоративный язык.

Мы не можем привести вам конкретные примеры, которые доказуемо не будут работать на языке Java, где дженерики были основаны на шаблонах и/или не было стирания.

• Этого гипотетического языка Java не существует.
• При достаточных усилиях разработчиков любая программа Java до версии 1.5 могла быть перенесена на такой язык.

При добавлении дженериков в язык Java команда Java хотела удовлетворить следующие требования (среди прочего):

• Код, скомпилированный для Java 4, и код, скомпилированный для Java 5, должны сосуществовать в одной и той же JVM и беспрепятственно взаимодействовать.
• Код библиотеки, написанный для Java 4, должен иметь возможность переноса на Java 5 таким образом, чтобы не нарушалась двоичная совместимость.

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

Основная трудность возникла из-за модификации структуры коллекций Java API с помощью универсальных шаблонов таким образом, чтобы не нарушать существующий код. Например, рассмотрим библиотеку Java 4, которая объявляет:

public List getFactories();

и используется в существующем приложении Java 4, которое выполняет:

List list = getFactories();

Теперь предположим, что приложение обновлено до Java 5 раньше, чем библиотека. Параметр какого типа они указывают? Они могли сказать:

• List factories = getFactories();

  ... но это лишает новый код возможности использовать дженерики

• List<Object> factories = getFactories()

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

• List<Factory> factories = getFactories();

  ... но это не было бы безопасным типом: поскольку среде выполнения не был сообщен параметр типа при создании объекта List, он не может проверить, что List содержит только фабрики (или обеспечить, чтобы это оставалось так, как унаследованный код продолжает общаться с List)

• List<Factory> factories = new ArrayList<Factory>(getFactories);

  ... что бы сработало, но копирование всего списка может быть медленным

Команда Java выбрала вариант 3 и частично смягчила последствия, потребовав от компилятора предупреждения об отсутствии безопасности типов и заставив компилятор вставлять синтетические приведения для проверки типа каждого отдельного объекта в списке перед использованием, тем самым сохраняя целостность системы типа времени выполнения с небольшим ущербом для производительности (и значительной ценой здравомыслия разработчика, когда такое приведение не удалось).

Интересно отметить, что группа разработчиков C#, столкнувшаяся с теми же затруднениями при внедрении обобщений в C# и CLR несколькими годами ранее, решила нарушить обратную совместимость, чтобы материализовать обобщенные типы. Как следствие, им пришлось ввести совершенно новую структуру коллекций (вместо того, чтобы просто модифицировать существующую структуру коллекций, как это сделала Java).

Оглядываясь назад, я думаю, что команда .NET сделала здесь лучший выбор, потому что это позволило им развивать язык, а не увековечивать его ограничения. По крайней мере, обоснование их дизайнерских решений спустя десятилетие не нуждается в объяснении :-)