Перейти к основному содержимому

Релизы Java, основанные на времени

· 5 мин. чтения

1. Введение

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

Изменения в расписании выпуска включают обновление функций и уровней поддержки для версий Java. В целом эти изменения заметно отличаются от Java, поддерживаемой Oracle с 2010 года.

2. Почему шестимесячные релизы?

Для тех из нас, кто привык к исторически медленной частоте выпуска Java, это довольно значительное отклонение. Почему такое резкое изменение?

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

Проще говоря, более короткие периоды выпуска приводят к меньшим, более управляемым шагам вперед. А мелкие функции легче принять.

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

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

3. Изменение номера версии

Механическим аспектом этого изменения является новая схема нумерации версий.

3.1. Схема строки версии JEP 223

Мы все знакомы со старым, кодифицированным в JEP 223 . Эта схема сделала номера версий добавочными и передала дополнительную информацию.

Actual                    Hypothetical
Release Type long short
------------ ------------------------
Security 2013/06 1.7.0_25-b15 7u25
Minor 2013/09 1.7.0_40-b43 7u40
Security 2013/10 1.7.0_45-b18 7u45
Security 2014/01 1.7.0_51-b13 7u51
Minor 2014/05 1.7.0_60-b19 7u60

Если мы запустим java -version на JVM для версии 8 или старше, мы увидим что-то вроде:

>java -version
java version "1.6.0_27"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07)
Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)

В этом случае мы можем предположить, что это для Java 6, что правильно, и для 27-го обновления, что неверно. Схема нумерации не так интуитивно понятна, как кажется.

Второстепенные релизы были кратны 10, а релизы безопасности заполнили все остальное. Как правило, мы видим, что короткая строка добавляется к нашим локальным установкам, таким как JDK 1.8u174. Следующим выпуском может стать JDK 1.8u180, это будет второстепенный выпуск с новыми исправлениями.

3.2. Новая схема версии-строки

Согласно Марку Рейнхолду в JEP , новая схема строки версий будет « преобразовывать номера версий, чтобы кодировать не совместимость и значимость, а, скорее, течение времени с точки зрения циклов выпуска » .

Давайте посмотрим на некоторые:

9.0.4
11.0.2
10.0.1

На первый взгляд кажется, что это семантическое управление версиями ; Однако, это не так.

При семантическом управлении версиями типичная структура $MAJOR.$MINOR.$PATCH , но новая структура версии Java:

$FEATURE.$INTERIM.$UPDATE.$PATCH

$FEATURE — это то, что мы можем считать основной версией , но она будет увеличиваться каждые шесть месяцев независимо от гарантий совместимости. И $PATCH для отладочных выпусков. Но на этом сходство заканчивается.

Во- первых, $INTERIM — это заполнитель, зарезервированный Oracle для будущих нужд. В настоящее время он всегда будет равен нулю.

И, во-вторых, $UPDATE зависит от времени, как и $FEATURE, обновляясь ежемесячно после выпуска последней функции.

И, наконец, конечные нули усекаются.

Это означает, что 11 — это номер выпуска для Java 11, выпущенного в сентябре 2018 года, 11.0.1 — его первое ежемесячное обновление в октябре, а 11.0.1.3 — это гипотетический третий выпуск исправления по сравнению с октябрьской версией.

4. Дистрибутивы с несколькими версиями

Далее, давайте посмотрим, как выбрать правильную версию.

4.1. Стабильность

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

На быстром канале язык выпускает функции в инкубации. Эти языковые функции стабилизируются в версии LTS.

Таким образом, для компаний, которые могут использовать волатильность в обмен на использование новых функций, они могут использовать быстрый канал. Предприятия, которые ценят стабильность и могут подождать с обновлением, могут обновляться при каждом выпуске LTS.

Экспериментирование с версиями JDK позволяет разработчикам найти наиболее подходящую.

4.2. Поддерживать

Есть еще, конечно, вопрос поддержки. Теперь, когда поддержка Java 8 закончилась, что нам делать?

И, как обсуждалось ранее, ответ приходит в версиях LTS, Java 11 — самая последняя версия LTS, а 17 — следующая . Обновления будут доступны и поддерживаться такими поставщиками, как Oracle и Azul.

Если мы можем доверять поддержке сообщества, то Redhat, IBM и другие заявили о своей поддержке применения исправлений ошибок для OpenJDK. Кроме того, проект AdoptOpenJDK предоставляет готовые двоичные файлы для OpenJDK.

4.3. Лицензирование

Одной из областей путаницы для некоторых является разница между OpenJDK и Oracle JDK.

На самом деле, по словам Брайана Гетца , они почти идентичны, отличаются только исправлениями ошибок и исправлениями безопасности .

OpenJDK выступает в качестве источника большинства производных JDK и остается бесплатным. Начиная с Java 11, Oracle будет взимать плату за коммерческую лицензию на Oracle JDK с включенной дополнительной поддержкой и услугами.

4.4. Фрагментация

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

Конечно, контейнеризация может помочь решить эту проблему. От Docker и CoreOS до OpenShift от Red Hat контейнеризация обеспечивает необходимую изоляцию и больше не заставляет использовать одно место установки для Java на сервере.

5. Вывод

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

Давайте помнить о некоторых последствиях, когда мы решаем, каков наш канал обновления, если нам нужна поддержка и лицензирование, и как справиться с фрагментацией.