Должна ли Java нарушать обратную совместимость в будущих версиях в пользу более чистого языка?

Как я уже уже упоминал, даже в его Как и когда объявлять API устаревшими, ничего не говорится о политике, касающейся фактического удаления устаревшие API...

Количество приложений, основанных на старой JVM (например, 1.4), по-прежнему важно, отчасти из-за серверов приложений, которым требуется много времени для проверки себя с новыми версиями JVM...

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

Существует несколько типов обратной совместимости:

1. Может ли старый исходный код скомпилироваться новым компилятором?

   С этим можно справиться с помощью инструментов, преобразующих старые конструкции в новые, или с помощью чего-то вроде «исходного кода 1.6»; директива в верхней части файла.

2. Могут ли старые файлы классов работать в новой JVM?

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

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

3. Могут ли старые файлы классов вызывать код, скомпилированный новым компилятором?

   Это важная часть # 2 из-за обратных вызовов.

4. Может ли вновь скомпилированный код вызывать код из старых файлов классов?

   Еще одна важная часть № 2.

5. Код выглядит существенно похожим на разработчиков?

   Это важно для обучения и для работы с большими кодовыми базами, которые не были полностью преобразованы. Более тонкий аспект заключается в том, какую часть новой функции можно использовать в смешанной кодовой базе. Если вы зайдете слишком далеко, у вас будет что-то вроде Scala вместо Java++.

Универсальные шаблоны были добавлены таким образом, чтобы сохранить все эти типы совместимости. Я думаю, что любое несовместимое изменение в Java должно сохранить по крайней мере 2, 3 и 4, чтобы иметь шанс быть принятым как Java. Инструменты для обработки № 1 также являются минимальным требованием.

Вы можете сделать это с помощью хобби (Ruby), языков с низкой реализацией (Python), но вы не можете себе представить, сколько приложений написано на Java по всему миру. Просто проверьте свежее мясо или sourceforge. И это только часть. Так что нет, это не очень хорошая идея. На самом деле, это была бы довольно глупая идея.

Не существует двух графических интерфейсов. Swing зависит и использует AWT в качестве основы.

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

Когда дело доходит до добавления новых языковых функций, я не до конца понимаю мантру обратной совместимости. На мой взгляд, это не так уж важно, если код, написанный для предыдущей версии, нуждается в некоторых изменениях для запуска в более поздней версии. На самом деле для этого в любом случае есть прецедент; между версиями 1.5 и 1.6 в интерфейс ResultSet были добавлены дополнительные методы, поэтому код, который будет компилироваться и работать в Java 1.5, даже не будет компилироваться в версии 1.6.

Учитывая устаревшие приложения, разумно ли ожидать, что приложение, которое не обновлялось в течение 5 лет, будет отлично работать на последней версии JVM? Если организации все еще используют Java 1.4 и приложения, написанные для нее, действительно ли их волнует, что входит в Java 7? Нарушение обратной совместимости не означает, что все предыдущие версии JVM также будут сломаны. Если приложение предназначено для более ранней версии, его можно без проблем запустить на этой версии JVM.

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

Конечно, нужно было бы подумать о пути обновления. Например, внезапное изменение целых чисел на целые потребовало бы массы утомительных изменений кода для всех (а также необходимости добавления дополнительных проверок нулей и т. д.). Однако добавление новой функции, нарушающей обратную совместимость (например, замыкания), или удаление методов, которые уже давно считаются устаревшими, мало повлияет на существующий код. (Если вы использовали устаревшие методы, то жестко, вы должны были удалить их раньше, но теперь вы вынуждены!)

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

Однако я думаю, что Sun могла бы выпустить выпуск «Java X», в котором было бы удалено все, что было грубым, и добавлены все хорошие и полезные API-интерфейсы, которые существуют, но в настоящее время не включены (включая замену API-интерфейсов Java, которые имеют лучшие доступные альтернативы, например, log4j, и не будем начинать с даты и календаря). Этот выпуск не предназначен для замены Java, но может использоваться в качестве цели для новых программных проектов. Я предполагаю, что они также могли бы исправить язык, включив в него отсутствующие функции, из-за которых Java выглядит немного грубо по сравнению с последними версиями C# и т. д. Если бы они также сделали инструмент переноса кода, который мог бы исправить или, по крайней мере, добавить "ИСПРАВИТЬ" все проблемные области в кодовой базе...

Должен признать, Microsoft хорошо справляется с переводом людей на более новые версии .NET, когда они выходят. Sun полностью потерпела здесь неудачу, учитывая количество приложений, все еще работающих на 1.4, и вялую политику версий Java многих компаний (которые, кажется, рады позволить своим .NET-людям каким-то образом использовать самые последние и лучшие версии). Учитывая, что установить несколько установок Java на машине несложно, я думаю, что следует сделать больше, чтобы стимулировать компании и компании-производители программного обеспечения к более раннему обновлению.

Я бы сказал, что нарушение обратной совместимости — глупая вещь для java. Если это так, вы можете называть это Java++, это уже не Java. С другой стороны, для будущих версий Java следует учиться на динамическом языке для таких функций, как простота синтаксиса. Поскольку аппаратная мощность растет очень быстро, уровень абстракции должен быть выше для компилирующего языка. Сравнивая некоторые особенности текущих версий Java с динамическими языками, он слишком громоздкий и многословный, а значит, менее продуктивный для разработки. Кажется, C# становится динамическим языком?

Учитывая множество отличных альтернативных языков на JVM, я действительно не вижу причин для этого. Я бы предпочел иметь стабильную Java и перейти к новым интересным вещам (и при этом оставаться совместимым с Java).

Поскольку большая часть рынка по-прежнему использует старые версии jdk/jre, я не думаю, что было бы прагматично нарушать обратную совместимость.

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

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

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

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

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

Причина, по которой я оставил PHP, заключается в том, что они меняют API/доступные функции между основными обновлениями версии. Настоящая проблема заключается в том, что PHP не может работать в режиме совместимости для старых скриптов. Я не хочу, чтобы меня ЗАСТАВЛЯЛИ обновлять мой код.

Java находится в том же месте. Просто убедитесь, что вы можете использовать старые версии 1.4 в новых версиях. Это нормально — требовать, чтобы новые программы использовали новый xyntax, но заставьте работать старые!

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

Обратная совместимость очень важна, и, как уже упоминалось здесь, многие пользователи все еще используют код 1.3 и 1.4. Сказав это, я думаю, что если кто-то все еще использует код Java 1.0 или 1.1 в какой-либо устаревшей системе, он вряд ли перейдет на Java 7 в ближайшее время, и даже если они это сделают, им, скорее всего, придется переписать свой код. код в любом случае. Я думаю, что устаревший API версий > 1.2 можно смело удалять.

Еще одним аспектом обратной совместимости является добавление ключевых слов, что всегда не рекомендуется. в Java 5 основные языковые изменения были реализованы за счет добавления одного нового ключевого слова «enum», и даже это вызвало возмущение, поскольку каждый фрагмент кода с переменной с именем «enum» теперь не соответствовал требованиям. Насколько я знаю, изменения в Java 7 планируются без новых ключевых слов (уф!).

Юваль =8-)

Это будет хорошо, если Sun не будет распространять новые обновления JDK для всех своих клиентов. Те, кто использует старые API, не будут обновляться и какое-то время будут использовать JDK старой версии.

Или, возможно, внедрив режим обратной совместимости.

Я думаю, что некоторые API, например дату и время, следует переписать. Если текущая версия получает EOL, то старый API следует удалить. Наша статистика показывает, что 99,3 % наших клиентов используют Java 6 или новее. Нет необходимости в совместимости очень старого API. Но должны быть четкие временные рамки, если API будет удален.