Рубрики
Без рубрики

Выпуски Java, основанные на времени

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

Автор оригинала: Kyle Doyle.

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 -версия на 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.

Если мы можем доверять поддержке сообщества, то Red hat, IBM и другие заявили о своей поддержке применения исправлений ошибок для OpenJDK. Кроме того, проект Adopt OpenJDK предоставляет готовые двоичные файлы для 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, перспектива появления новых языковых функций каждые шесть месяцев является захватывающей.

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