Фон

Это не так сразу видно, как вы думаете.

Во-первых, в то время как Oracle прекратила публичную поддержку Java 6 с февраля 2013 года, но с поддержкой Premier выйдет на декабрь 2013 года и расширенная поддержка, идущая к декабрю 2016 года немного длинный хвост. Кроме того, существует устойчивая поддержка, которая может продолжаться вечно.

Следующий крупный поставщик Java, IBM, похоже, даже не опубликовал конец поддержки Java 6 (и по-прежнему поддерживает Java 5 до сентября 2013 года! )

В-третьих, у нас есть Apple: с последним последним патчем в июне 2013 года и "компания не указала свои политики поддержки в черно-белом режиме" кажется, кто-то догадывается... но если они будут обрабатывать Java 5 в качестве основы, мы можем увидеть еще 18 месяцев или около того... конец 2014 года?

Наконец, у нас есть OpenJDK..., который Red Hat сказал, что теперь будет поддерживать...

И я даже не приступал к рассмотрению других реализаций JVM только более распространенных в дикой природе!

Итак, из того, что я вижу, до сих пор, пока у вас есть деньги для оплаты Oracle/IBM/Red Hat, вы можете продолжать получать версию Java 6, которая поддерживается неограниченно...

Возможно, мы сможем начать формулировать этот вопрос немного лучше и получить шанс на неопределенный ответ:

Если вы не можете купить аппаратное обеспечение/операционную систему, с которой работает JVM, то определенная JVM, которая продолжает поддерживаться, немного спорна. Расширенные контракты на поддержку для существующих клиентов, которые, скорее всего, имеют свои существующие потребности в своих существующих системах... и если они не могут перейти на более новый

Это фактически дает нам некоторый контекст для Apple... поскольку аппаратное обеспечение Apple поддерживается в течение 5 лет (7, если в Калифорнии), то единственным поддерживаемым аппаратным обеспечением Apple должно быть оборудование на базе x86, поскольку коммутатор был завершен Декабрь 2006 (будучи последним аппаратным оборудованием Apple на базе PPC), поэтому на самом деле нам не нужно беспокоиться о версиях Apple Java, которые работают на PPC, в качестве

Аналогично, мы, вероятно, можем исключить любые версии Java, которые работают в более старых версиях Windows. Что означает Apr 2014, если установщик Java не будет запускаться в Windows 7+, тогда мы можем фактически игнорировать эту версию Java, поддерживаемую в Windows XP?
Мой реальный интерес - это когда разработчики могут продвигать свою минимальную версию Java.

Jenkins поддерживает поддержку Java 5 в течение некоторого времени, но более новые изменения означают, что 1.520 + требуется Java 6 или новее на главном и подчиненном устройствах. Это может вызвать проблемы, если некоторые из ведомых устройств сборки, например. устаревшее оборудование, не может запускать новые JVM.

Maven имеет давнюю историю, позволяющую разветкить JVM до J2SE 1.3 для запуска модульных тестов, но с Surefire 2.15, он будет поддерживать только те тесты, которые выполняются на уровне как Java 5.

javac переходит к политике 1 и 3 назад в терминах -source и -target... поэтому нам нужно будет подождать до JDK 10 до Поддержка исходных файлов Java 6 отключена из javac... с 2-летним релизом каденции и Java 8, запланированным к выпуску в начале 2014 года, что подразумевает JDK9 в начале 2016 года и JDK10 в начале 2018 года... но JDK9 будет доступен с общедоступным в течение еще 3 лет, что означает, что некоторое время в 2019 году, когда совместимость исходного кода JDK 6 может быть удалена.

Вопрос

Есть ли ясная дата, которая может быть использована для установления, когда инструментальные средства для разработчиков OSS могут отказаться от поддержки JVM до Java 7, и какова эта дата?

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

Обновление: "Отбросить поддержку для JVM до Java 7" Я имею в виду, что было бы безопасно скомпилировать всю инструментальную цепочку с помощью -target 7, то есть для того, чтобы байт-код требовал запускать Java 7.

Обновление 2: это должно быть, как указано в рамке, отвечать на вопрос, основанный на факте. Правильный ответ должен быть либо формы

Нет четкого ответа, вот ссылка на "некоторые люди, которые предоставляют бесплатные обновления для пользователей OSS на Java 6", и они не сказали, когда они еще остановятся.

или

Да, есть окончательная дата ГГГГ-ММ-ДД, и вот доказательства

Ответ 1

Есть ли ясная дата, которая может быть использована для установления, когда инструментальные средства для разработчиков OSS могут отказаться от поддержки JVM до Java 7, и какова эта дата?

Нет. Такой даты нет.

Люди, разрабатывающие цепочки инструментов, могут отказаться от поддержки версий EOL'd Java, когда им нравится... или вообще нет. Гипотетически, если физические лица (или компании) заключили договорные отношения с другими компаниями (например, клиентами) для оказания поддержки в течение определенного периода времени, то эти соглашения, очевидно, будут сдерживать их. Однако маловероятно, что это сдерживает проект в целом.

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

В случае версий OSS базы Java-кода вы (пользователь Java) находятся в лучшем положении:

Вероятно, существует определенный уровень поддержки/развития сообщества задолго до того, как это будет коммерчески выгодно для этого.
И если нет, у вас есть доступ к исходному коду, чтобы вы могли (теоретически) поддерживать себя или платить кому-то другому, чтобы сделать это за вас.

Стив Конолли прокомментировал:

Сообщество OSS не может заключать контракты на поддержку.

Это совершенно неправильно.

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

Кроме того, все основные лицензии OSS позволяют это... включая GPL и все его варианты.

Но если сообщество OSS не может вырастить разработчиков, потому что вы вообще не можете получить доступ к этой технологии без затрат, то это принудительно предотвращает поддержку pre-java 7.

Это тоже неправильно.

Sun (ранее), и теперь Oracle предлагает бесплатные загрузки версий EOL'ов бесплатных версий Java... все возвращается к Java 1.1. EOL-IN не изменяет доступность. Речь идет о доступности выпусков исправлений старых версий Java для недавно обнаруженных проблем безопасности и других ошибок. Вы должны заплатить за это. (Достаточно справедливо. Это стоит денег Oracle, чтобы выполнить эту работу.)

Проблема в том, что Java 5 и более ранние версии были доступны и не доступны в форме исходного кода. Это означает, что у клиентов нет реалистично возможности исправления (например) дыр в безопасности на Java 5. В отличие от этого, в Java 6 у них есть эта опция. Кодовая база OpenJDK 6 была выпущена как открытый источник, и это нельзя отменить. Более того, поскольку Java 7 и Java 8 также являются открытыми исходными кодами, пользователи могут отслеживать исправления безопасности в Java 7 и 8 и пытаться выполнить резервное копирование изменений в кодовую базу OpenJDK 6...