От переводчика Недавно в мире Java произошло несколько важных событий: Марк Рейнхольд опубликовал письмо, в котором предложил перейти на полугодовой график выпуска Java, за этим последовало сообщение от Oracle, где предлагают ряд серьезных изменений в работу над OpenJDK:
- Начиная с JDK 9 GA, Oracle будет выпускать сборки OpenJDK под лицензией GPL.
- Java SE перейдет на постоянный график выпуска (письмо от Марка)
- Oracle перенесет в OpenJDK ранее коммерческие функции (например, Java Flight Recorder)
- Oracle будет сотрудничать с другими разработчиками OpenJDK, чтобы предоставить современную, полную и доступную среду.
Мне кажется, это очень важный и нужный шаг для Java как платформы.
Ниже я предлагаю перевод письма Марка, в котором объясняется, как будет работать новый график релизов.
Ускоренное продвижение Java вперед За более чем 20 лет платформа Java SE и JDK продвигались вперед большими, нерегулярными и непредсказуемыми шагами.
Каждый фич-релиз определялся какой-то главной фичой и график релизов менялся — иногда не один раз! — чтобы подстроиться под график разработки этой функции.
Такой подход позволил включить в релиз новый функционал максимально качественно, после тщательного рассмотрения и тестирования.
Однако недостатком этого подхода является то, что меньшие функции API, языка и платформы могут быть включены в окончательную версию только тогда, когда дом функция готова.
Это был разумный компромисс в десятилетия до и после начала века, когда конкурентами Java было несколько платформ, которые росли такими же медленными темпами.
Однако в наши дни конкуренты Java движутся гораздо быстрее.
Чтобы Java оставалась конкурентоспособной, мы должны не просто двигаться вперед — мы должны двигаться быстро.
Поезд снова Пять лет назад я отражено в этом блоге о разнице между разработчиками, предпочитающими быстрые инновации, и предприятиями, предпочитающими стабильность, а также о том, что по сути все предпочитают регулярные и предсказуемые выпуски.
Для решения проблем обеих я тогда предложил перейти от исторической модели релиза, где релиз определяется набором функций, к «поездной» модели, когда релиз выходит строго по графику, каждые два года.
.
При таком подходе разработка может отходить от релиза и вводить новшества, а релиз, независимо от разработки, имеет постоянный график.
Любая функция, большая или маленькая, включается в релиз только тогда, когда она (почти) полностью готова.
Если развитие фичи не догонит текущий релизный «поезд», это неприятно, но не конец света, т.к.
следующий «поезд» отправится строго по расписанию.
Модель поезда с двухгодичным графиком движения в теории выглядела хорошо, но на практике оказалась неработоспособной.
На создание Java 8 у нас ушло дополнительно 8 месяцев.
закрыть критические проблемы безопасности и завершить проект Lambda , и это было предпочтительнее, чем откладывать лямбды на два года.
Первоначально мы даже планировали, что Java 9 будет выпускаться 2,5 раза в год и включать в себя Проект Пазл , чтобы не задерживать его на 18 месяцев до следующего «поезда».
Но в конце концов нам понадобился еще год разработки, а Java 9 выйдет только в этом месяце, через 3,5 года после Java 8. Оглядываясь назад, можно сказать, что двухлетний цикл выпуска был слишком медленным.
Чтобы добиться регулярного графика, мы должны выпускать релизы гораздо чаще.
Перенос функции в следующую версию должен быть тактическим решением с минимумом неудобств, а не глобальным решением с серьезными последствиями.
Итак, мое предложение: давайте выпускать каждые шесть месяцев .
Это достаточно быстро, чтобы избежать хлопот с ожиданием следующего выпуска, но достаточно медленно, чтобы выпуски оставались высокого качества.
Предложение Вдохновленный примером графика выпуска других платформ и операционных систем, я предлагаю после выпуска Java 9 перейти к строгому, регулярному графику выпуска с выпуском новой функции каждые шесть месяцев, выпуском обновлений каждый квартал и выпуск LTS (долгосрочная поддержка) каждые три года.
- Функциональный выпуск может содержать любые функции, включая не только новые или обновленные API, но также функции языка и JVM. Новые функции будут добавлены в версию на заключительных этапах, поэтому текущая версия должна быть полностью функциональной в любой момент времени.
Функциональные выпуски будут выпускаться два раза в год, в марте и сентябре, начиная с марта 2018 года.
.
- Обновление выпуска будет строго ограничено исправлениями проблем безопасности, регрессионных ошибок и ошибок в новых функциях.
Каждый выпуск функции получит два выпуска обновлений.
Релизы обновлений будут выходить ежеквартально, в январе, апреле, июле и октябре.
.
- Каждые три года, начиная с сентября 2017 г.
, выпуск функции станет LTS-релиз .Обновления для выпусков LTS будут доступны в течение как минимум трех лет, а возможно, и дольше, в зависимости от поставщика.
Однако ключевое отличие состоит в том, что у разработчиков JDK будет гораздо больше возможностей для выпуска новых функций.
Шестимесячный выпуск функций будет меньше, чем многолетний выпуск с множеством новых функций в прошлом, и поэтому на него будет легче перейти.
Шестимесячный релиз также уменьшит трудности с переносом кода на старые релизы (бэкпорт), ведь разница между ними не будет превышать 6 месяцев.
Разработчики, предпочитающие инновации и новые функции, смогут использовать новые выпуски функций или последние доступные версии обновлений.
Они смогут упаковывать приложения в контейнеры Docker или контейнеры любого другого типа, указав точную версию Java, которая им нужна.
При таком подходе новый выпуск Java и приложение можно легко протестировать на совместимость с использованием современных конвейеров CI/CD, и переход на новый выпуск будет простым.
Корпоративные разработчики, которые предпочитают стабильность, позволяющую запускать несколько крупных приложений в одной общей версии Java, смогут использовать LTS вместо функциональных выпусков.
Они также смогут планировать обновления для следующего LTS строго по графику, каждые три года.
Чтобы помочь ориентироваться в новых выпусках по строгому графику и легко понять, когда был выпущен конкретный выпуск, версия выпуска будет выглядеть как $YEAR.$MONTH. То есть следующий мартовский релиз будет 18.3, а сентябрьский LTS — 18.9. Последствия Это предложение, если оно будет принято, потребует серьезных изменений в том, как вкладчики Сообщество OpenJDK производится непосредственно JDK. я обрисовал в общих чертах ряд мыслей на этот счет. Этот процесс станет намного проще, если мы сможем сократить накладные расходы, создаваемые процессом сообщества Java, который контролирует разработку платформы Java SE; Мои коллеги Брайан Гетц И Джордж Суб уже поднятый этот вопрос для обсуждения с Исполнительный комитет JCP .
Это предложение в конечном итоге повлияет на каждого разработчика, пользователя и компанию, использующую Java. Это также, в случае успешной реализации, поможет Java оставаться конкурентоспособной, по-прежнему опираясь на набор ценностей, таких как обратная совместимость, надежность и продуманное развитие, на многие годы вперед. Теги: #openjdk #oracle #java 9 #программирование #java
-
Стимпанк В Мобильных Телефонах И Компьютерах
19 Oct, 24 -
Вы Пользовались Интернетом, %Username%?
19 Oct, 24 -
Сброс Стилей С Помощью Css Reset
19 Oct, 24 -
Активация Windows 7 Была Полностью Сломана
19 Oct, 24 -
Спорт И Некоторые Линейные Уравнения
19 Oct, 24 -
Protonmail Вышел Из Тени
19 Oct, 24 -
Новогоднее Поздравление От Робота
19 Oct, 24
