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

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

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

   Это можно обработать с помощью инструментов, которые преобразуют старые конструкции в новые, или с чем-то вроде директивы "source 1.6;" в верхней части файла.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

однако я думаю, что Sun может сделать выпуск "Java X", который удалил все, что было crufty, и добавил Все хорошие и полезные API, которые есть, но в настоящее время не включены (включая замену Java APIs, которые имеют лучшие альтернативы доступно, например, log4j, и давайте не будем начинать с даты и календаря). Этот выпуск не будет предназначен для замены Java, но может существовать в качестве цели для новых проектов программного обеспечения. Я думаю, они также могут исправить язык, чтобы включить отсутствующие функции, которые делают Java немного грубым по сравнению с последними версиями C# и т. д. Если они также сделали инструмент переноса кода, который мог бы исправить или, по крайней мере, добавить "FIXME" ко всем проблемным областям в кодовой базе ...

должен признать, 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 планируются без новых ключевых слов (phew!).

Юваль =8-)

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

или, возможно, путем реализации режима обратной совместимости.

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