От переводчика
Недавно в мире Java случилось пара важных событий: Марк Рейнхольд опубликовал письмо, в котором предложил перейти на полугодовой график релизов Java, а за этим последовало сообщение от Oracle, где они предлагают ряд серьезных измненеий в работе над OpenJDK:
- Начиная с JDK 9 GA, Oracle будет выпускать OpenJDK билды под GPL лицензией
- Java SE перейдет на постоянный график релизов (письмо Марка)
- Oracle внесет ранее коммерческие фичи (как Java Flight Recorder) в OpenJDK
- Oracle будет сотрудничать с другими разработчиками OpenJDK чтобы обеспечить современню, полную и доступную среду
Несмотря на то, что коммерческая версия Oracle JDK останется, целью компании станет сделать ее полностью совместимой и взаимозаменяемой с OpenJDK (до конца 2018).
Как мне кажется, это очень важный и нужный шаг для Java как платформы. Ниже я предлагаю перевод письма Марка, которые поясняет как будет работать новый график релизов.
Moving Java forward faster
На протяжении более чем 20 лет, платформа Java SE и JDK двигались вперед большими, нерегулярными и непредсказуемыми шагами. Каждый feature-release определялся какой-то основной фичей и график релиза менялся — иногда и не один раз! — чтобы подстроится под график разработки этой фичи.
Этот подход сделал возможным включение нового функционала в релиз с высочайшим качеством, после тщательного ревью и тестирования. Недостатком этого подхода, однако, является то, что более мелкие фичи API, языка и платформы могут быть включены только в финальный релиз, когда главная фича готова.
Это был разумный компромисс десятилетиям до и после начала века, когда конкурентами Java были всего несколько платформ, которые развивались такими же медленными темпами. В наши дни, однако, конкуренты Java развиваются гораздо быстрее.
Чтобы Java могла оставаться конкурентоспособной, мы должны не просто двигаться вперед — мы должны двигаться быстро.
Снова поезд
Пять лет назад я размышлял в этом блоге о разнице между разработчиками, которые предпочитают быстрые инновации, и энтерпрайзом, который предпочитает стабильность, а так же фактом, что все, в сущности, предпочитают регулярные и предсказуемые релизы.
Чтобы решить проблемы и тех, и других, я тогда предолжил что мы должны перейти с исторической модели релизов, где релиз определяется набором фич, к модели "поезда", когда релиз выходит строго по расписанию, раз в два года. С таким подходом, разработка может не подстраиваться под релиз и заниматься инновациями, а релиз, независимо от разработки, имеет постоянный график. Любая фича, большая или маленькая, включается в релиз только когда (почти) полностью готова. Если разработка фичи не успевает на текущий релизный "поезд" — это неприятно, но не конец света, т.к. следующий "поезд" отправиться строго по расписанию.
Модель "поезда" с двухгодичным графиком выглядела неплохо в теории, но доказала свою неработоспособность на практике. Нам потребовалось дополнительные 8 месяцев для Java 8 чтобы закрыть критические проблемы безопасности и закончить проект "Лямбда", и это было предпочтительнее, чем откладывать лямбды на два года. Изначально мы даже планировали Java 9 как 2.5 годичный релиз, чтобы включить туда Project Jigsaw, чтобы не задерживать его на 18 месяцев до следующего "поезда". Но в конец-концов нам потребовался еще один год на доработку, и Java 9 выйдет только в этом месяце, через 3.5 года после Java 8.
Оглядываясь назад можно сказать, что двухгодичный цикл релизов просто слишком медленный. Чтобы добиться регулярного графика мы должны выпускать релизы гораздо чаще. Перенос фичи на следующий релиз должен представлять собой тактическое решение с минимумом неудобств, вместо глобального решения с серьезными последствиями.
Итак, мое предложение: давайте выпускать релизы каждые шесть месяцев.
Это достаточно быстро, чтобы избежать проблем от ожидания следующего релиза, но достаточно медленно, чтобы релизы могли оставаться высокого качества.
Предложение
Воодушевившись примером релизного графика других платформ и операционных систем, я предлагаю, после релиза Java 9, перейти на строгий, регулярный график релизов с новым feature-релизом каждые шесть месяцев, update-релизом каждый квартал и LTS (long term support) релизом каждые три года.
- Feature-релиз может содержать любые фичи, включая не только новые или обновленные API, но так же фичи языка и JVM. Новые фичи будут внесены в релиз тогда на финальных стадиях, так что текущий релиз должен быть feature-complete в любой момент времени. Feature-релизы будут выпускаться дважды в год, в марте и сентябре, начиная с марта 2018 года.
- Update-релиз будет строго ограничен исправлениями проблем с безопасностью, регрессионных багов, и багов в новых фичах. Каждый feature-релиз полчит два update-релиза. Update-релизы будут выпускаться ежеквартально, в январе, апреле, июле и октябре.
- Каждые три года, начиная с сентября 2017, feature-релиз будет становится LTS релизом. Обновления для LTS релизов будут доступны как минимум три года, а возможно и дольше, в зависимости от поставщика.
При такой модели общая скорость изменений должна быть такой же, как сегодня. Однако ключевое отличие, что у разработчиков JDK будет гораздо больше возможностей выпускать новые фичи. Полугодовой feature-релиз будет меньше, чем многолетний релиз с кучей новых фич в прошлом, и поэтому на него будет проще переходить. Полугодовой релиз так же уменьшит сложности с портированием кода в старые релизы (backport), т.к. разница между ними не будет превышать 6 месяцев.
Разработчики, которые предпочитают инновации и новые фичи смогут использовать новые feature-релизы или последние доступные update-релизы. Они смогут упаковывать приложения в Докер контейнеры, или любые другие типы контейнеров, указывая точную версию Java, которая им необходима. С таким подходом, т.к. новый релиз Java и приложение могут быть легко протестированы на совместимость с помощью современных CI/CD pipeline-ов, переход на новый релиз будет простым.
Энтерпрайзные разработчики, которые предпочитают стабильность, чтобы они могли запускать несколько больших приложений на одном, общем Java-релизе, смогут использовать LTS вместо feature-релизов. Так же они смогут планировать обновление на следующий LTS строго по расписанию, каждые три года.
Чтобы ориентироваться в новых релизах со строгим графиком и чтобы легко понять, когда был выпущен тот или иной релиз, версия релиза будет выглядеть как $YEAR.$MONTH. То есть, следующий мартовский релиз будет 18.3, а сентябрьский LTS будет 18.9.
Последствия
Это предложение, если будет принято, потребует серьезных изменений в том, как контрибьюторы в OpenJDK Community производят непосредственно JDK. Я изложил ряд мыслей на этот счет. Этот процесс будет гораздо проще, если мы сможем уменьшить накладные расходы, создаваемые Java Community Process, которые курирует развитие платформы Java SE; мои коллеги Брайн Гетз и Джордж Саб уже подняли этот вопрос на обсуждения с JCP Executive Committee.
Это предложение в конце-концов, затронет каждого разработчика, пользователя и компанию, которые полагаются на Java. Оно так же, если будет успешно внедрено, поможет Java оставаться конкурентоспособной, однако по прежнему опираться на набор таких ценностей, как обратная совместимость, надежность и продуманное развитие на многие годы вперед.
Автор: alek_sys
