Java должен повредить назад совместимость в будущих версиях в пользу более чистого языка? [закрытый]
Вы можете использовать API проблем поиска , используя следующие параметры поиска:
- репо: имя пользователя / репо
- состояние: открыто
- метка: «конфликт слияния» (отметьте этот )
В интерфейсе пользователя: https://github.com/search?q=repo%3AMacley-Kun% 2Favaire + состояние% 3Aopen + метка% 3A% 22merge + конфликт% 22
Использование Github API Rest v3
Использование bash с curl & амп; jq , чтобы проверить, если в этом репо хотя бы одна проблема помечена как «конфликт слияния» (без учета регистра)
query='repo:Macley-Kun/avaire state:open label:"merge conflict"'
merge_conflicts=$(curl -G -s "https://api.github.com/search/issues" \
--data-urlencode "q=$query" | jq '.items | length')
if [ "$merge_conflicts" -eq 0 ]; then
echo "no opened merge conflicts issue detected"
else
echo "one or many merge conflicts issues already exist"
fi
Использование Github API Graphql v4
{
search(query: "repo:Macley-Kun/avaire state:open label:\"merge conflict\"", type: ISSUE, first: 0) {
issueCount
}
}
[1110 ] Попробуйте это из проводника
Используя bash с curl & amp; JQ :
repo=Macley-Kun/avaire
merge_conflicts=$(curl -s -H "Authorization: token $YOUR_TOKEN" \
-H "Content-Type:application/json" \
-d '{
"query": "{search(query: \"repo:'"$REPO"' state:open label:\\\"merge conflict\\\"\", type: ISSUE, first: 0) {issueCount}}"
}' https://api.github.com/graphql | jq '.data.search.issueCount')
if [ "$merge_conflicts" -eq 0 ]; then
echo "no opened merge conflicts issue detected"
else
echo "one or many merge conflicts issues already exist"
fi
15 ответов
Как я уже упомянул, даже в, Как и Когда Удержать от использования API, ничто не говорится о политике относительно фактического удаления API устаревших...
Количество приложений на основе более старой JVM (1.4, например) все еще важно, частично из-за серверов приложений, которые занимают много времени для проверки себя с новыми версиями JVM...
Чистое количество приложений, которые на самом деле работают в производстве, означает, что эта политика “обратной совместимости” не может быть повреждена в ближайшее время.
Это будет хорошо, в зависимости от Sun, не пихающего новые обновления JDK всех его клиентов. Те, кто использует старые API, не обновят и будут использовать старую версию JDK некоторое время.
Или, возможно, путем реализации назад-режима-эмуляции.
Относительно примитивов они всегда будут там, нравится или нет, потому что они - основные стандартные блоки объектов. Несомненно, Вы могли использовать классы обертки вместо этого, но это просто переутомляет компилятор, который в конечном счете переводит назад в примитивы в большинстве случаев.
Обратная совместимость очень важна, и как люди, уже упомянутые здесь, существует много пользователей, все еще выполняющих 1,3 и 1,4 кода. Сказав это, я думаю, выполняет ли кто-либо все еще java 1.0 или 1,1 кода в некоторой унаследованной системе, они вряд ли мигрируют на Java 7 в ближайшее время, и даже если они делают, они должны будут, скорее всего, переписать свой код так или иначе. Я думаю, что API устаревший версий> 1.2 может безопасно быть удален.
Другим аспектом обратной совместимости является добавление ключевых слов, которому всегда препятствуют. в Java 5 главными изменениями языка управляли с добавлением единственного нового ключевого слова, 'перечисления', и даже который вызвал негодование, так как каждая часть кода с переменной, названной 'перечислением', была теперь несовместима. Насколько я знаю, изменения в Java 7 планируются без новых ключевых слов (уф!).
Yuval =8-)
Я думаю, что ветвление было бы более соответствующим, чтобы дать языку надлежащую перестройку. Путем работа дженериков Java начинает бесить меня, откровенно.
Повреждение совместимости имело бы смысл, если JVM сохраняет то же. В этом случае "новый" Java стал бы новым, другим языком, работающим на JVM, такой как перечисленные там. К счастью, способ, которым JVM разработана совместимость гарантий между языками и версиями, таким образом, я думаю влияние, был бы ограничен.
Со многими большими альтернативными языками на JVM я действительно не вижу оснований почему. Я имел бы стабильный Java и движение для прохладного нового материала (и все еще остался бы совместимым с Java).
Я сказал бы, что повреждение назад совместимость является глупой вещью сделать для Java. Если так, можно назвать это Java ++, это больше не Java. С другой стороны, для будущих версий Java, это должно извлечь уроки из динамического языка для функций, таких как простота синтаксиса. Так как аппаратное питание увеличивается таким образом быстро изменяющийся, абстрактный уровень должен быть выше для языка компиляции. Сравнивая некоторые функции текущих версий Java с динамическими языками, это является слишком неуклюжим и подробным, таким образом менее продуктивным для разработки. Кажется, что C# становится динамическим языком?
Как Pat сказал, принятие новейшей версии JDK является довольно медленным, и много приложений в настоящее время выполняет старое использование (иногда действительно старый) версии Java.
Таким образом я не думаю, что существует реальная выгода не уверения назад совместимость.
Для Ваших предложений я действительно не вижу интереса удаления примитивов. Конечно, там автоупаковывает начиная с Java 5. Однако примитивы все еще имеют свои интересы...
Причина я оставил PHP, состоит в том, что они изменяют функции API / доступные функции между основными обновлениями версий. Настоящая проблема состоит в том, что PHP не может работать в режиме совместимости для более старых сценариев. Я не хочу быть ВЫНУЖДЕННЫМ обновить свой код.
Java находится в том же месте. Просто удостоверьтесь, что можно использовать старые 1,4 материала на новых версиях. Нормально требовать, чтобы новые программы использовали новый xyntax, но сделали старый материал выполненным!
Поскольку совместимость обосновывает, что они не могут сделать этого со стандартными выпусками Java. Существует так много программного обеспечения Java в производстве там прямо сейчас, что Вы просто не можете повредить его с новым выпуском, который удаляет весь хлам.
Однако я действительно думаю, что Sun мог сделать "Java X" выпусками, которые удалили все, что было неработоспособным, и добавило все хорошие и полезные API, которые являются там, но не в настоящее время включены (включая замену API Java, которые имеют лучшие альтернативы в наличии, например, log4j, и давайте не запускаться в Дату и Календарь). Этот выпуск не был бы разработан для замены Java, но мог существовать как цель для новых проектов программного обеспечения. Я предполагаю, что они могли также согласовать язык для включения функций, которые отсутствуют, которые заставляют Java выглядеть немного неработоспособным по сравнению с последними версиями C# и т.д. Если они сделали инструмент портирования кода также, который мог бы договориться или по крайней мере добавить "FIXME" ко всем проблемным областям в кодовой базе...
Должен признать, Microsoft делает хорошее задание углубления людей к более новым версиям.NET, когда они выходят. Sun полностью перестал работать здесь, дал количество приложений, все еще работающих 1.4, и летаргические политики управления версиями Java многих компаний (кто кажется счастливым позволить их людям.NET использовать последнее и самое большое так или иначе). Учитывая, что просто иметь несколько установок Java на машине, я думаю, что больше должно быть сделано, чтобы поощрить регистрационные палаты и фирмы по разработке программного обеспечения обновлять раньше.
Можно сделать это с хобби (Ruby), низкая реализация (Python) языки, но Вы не можете вообразить, сколько приложений записано в Java во всем мире. Просто проверьте freshmeat или SourceForge. И это - только часть. Так не, это не хорошая идея. На самом деле это была бы довольно глупая идея.
Нет двух платформ GUI. Swing зависит и использует AWT, поскольку это - основание.
С тех пор главная часть доли рынка все еще использует более старый jdk/jre, я не думаю, что это будет прагматично для повреждения обратной совместимости.
Существует несколько типов назад совместимости:
Старый исходный код может скомпилировать с новым компилятором?
Это может быть обработано с инструментами, которые преобразовывают старые конструкции в новые, или с чем-то как "источник 1.6"; директива наверху файла.
Старые файлы класса могут работать в новой JVM?
В моем мире это - полный выставочный стопор. Мы пользуемся таким количеством сторонних библиотек, что принуждение одновременного обновления всех их было бы слишком дорогостоящим.
Это - также драйвер для того, чтобы не удалять удержанные от использования классы и методы, но до меньшей степени.
Старые файлы класса могут назвать код скомпилированным с новым компилятором?
Это - важная часть № 2 из-за обратных вызовов.
Недавно скомпилированный код может назвать код из старых файлов класса?
Другая важная часть № 2.
Код выглядит существенно подобным разработчикам?
Это важно для обучения, и для рабочих больших кодовых баз, которые не полностью преобразовали. Более тонкий аспект - то, сколько из новой возможности может использоваться в смешанной кодовой базе. При повреждении этого слишком далеко у Вас есть что-то как Scala вместо Java ++.
Дженерики были включены такой, был как для сохранения всех этих типов совместимости. Я думаю, что любое несовместимое изменение в Java должно сохранить по крайней мере 2, 3 и 4, чтобы иметь любой шанс принятия как Java. Инструменты для обработки № 1 являются также минимальным требованием.
Я действительно наслаждался бы, если бы определенные устаревшие функции были удалены - например, если Date объект был действительно сделан неизменным, я буду очень счастлив. Как это, если Вы пишете неизменный класс, Вы не можете предположить, что Даты неизменны и должны оборонительно скопировать их, например, и Вы не можете надежно использовать их в качестве ключей в Hashmaps (так как в обоих случаях, другой код может видоизменить Дату независимо от того, аннотируются ли методы, как удерживается от использования или не).
Когда дело доходит до добавления новых опций языка я не полностью понимаю назад молитва совместимости. По моему мнению не случается так, что большой соглашение, если для кода, написанного для предыдущей версии, нужны некоторые тонкие настройки для выполнения в более поздней версии. На самом деле существует прецедент для этого так или иначе; между 1,5 и 1.6, дополнительные методы были добавлены к интерфейсу ResultSet, и таким образом, код, который будет компилировать и работать под Java 1.5, даже не скомпилировал бы под 1,6.
При рассмотрении приложений прежней версии действительно ли разумно для кого-то ожидать приложение, которое не было обновлено за 5 лет для выполнения отлично на последней версии JVM? Если организации все еще используют Java 1.4 и приложения, которые были записаны для него, они действительно заботятся о том, что входит в Java 7? Повреждение назад совместимость не означает, что все предыдущие версии JVMs станут поврежденными также. Если приложение предназначено для более ранней версии, можно просто выполнить его на той версии JVM без забот.
Самое главное, с течением времени и люди используют Java, ошибки и разрывы функции становятся очевидными, и исправляющий/реализующий их было бы главное благо. Будучи надетым смирительную рубашку при попытке улучшить язык из-за того, что прибыло прежде, если неудачный, и по моему мнению не фундаментальное требование.
Конечно, должна была бы быть некоторая мысль к процедуре обновления. Внезапно изменить ints на Целые числа, например, потребовало бы масс утомительных изменений кода для всех (а также имеющий необходимость добавить дополнительные пустые проверки, и т.д.). Однако добавление новой опции, которая, оказывается, повреждает назад совместимость (например, закрытия), или методы удаления, которые были удержаны от использования в течение многих лет, будет иметь мало эффекта на существующий код. (При использовании устаревших методов, затем жестких необходимо было удалить их прежде, но теперь Вы вынуждены к!)
Я думаю, что некоторые API, например, дата-время, должны быть переписаны. Если текущая версия получает EOL, то старый API должен быть удален. Наша статистика показывает, что 99,3 % наших клиентов используют Java 6 или новее. Нет необходимости в совместимости очень старых API. Но должны быть четкие временные рамки, когда API будет удален.