Translate
August 21, 2019

Opsian разговаривает с Алексеем Шипилевым об обновлениях JDK

Часть I
Ричард Варбертон из Opsian имел честь встретиться с Алексеем Шипилевым и узнать его мнения по целому ряду вопросов. В первой части интервью Алексей и Ричард обсуждают текущее состояние обновлений JDK.

Ричард: Для тех, кто не знает, кто вы есть, не желаете ли вы представиться или рассказать нам немного о себе?

Алексей: Привет, я Алексей Шипилев, занимаюсь Java и производительностью уже около 15 лет. Вероятно, я могу перечислить проекты, в которых я принимал участие в OpenJDK: различные инструменты, такие как JMH, JCStress и JOL. Я сделал несколько параллельных тестов, провел общую работу по повышению производительности и некоторые из них включали в себя JEP. После работы в Red Hat я также работал с Epsilon и Shenandoah и помогаю с обновлениями OpenJDK для Red Hat.

Ричард: Точно. И вы бы сказали, что большую часть времени проводите в эти дни, работая над Shenandoah?

Алексей: Я бы сказал, что это половина с половиной: Я трачу половину своего времени на работу с Shenandoah, а половину - на общую работу в JVM. Последние несколько месяцев были заняты выпуском обновлений с первой волной исправлений после того, как Red Hat взял на себя техобслуживание 8u и 11u. Мы надеемся, что сейчас объем работы снизится, поэтому я бы тратил на это, может быть, день в неделю, или что-то в этом роде. Но да, до сих пор я провожу много времени, занимаясь выпуском обновлений.

Ричард: Так наверное, это хорошее место для начала, потому что я думаю, что в Java сообществе в целом довольно много путаницы по поводу того, что происходит на самом деле с обновлениями. Существует множество " не бесплатных обновлений, не безопасности", много забот и всего остального. Я знаю, что есть несколько человек, которые выпустили более подробную документацию или информацию - возможно, вы захотите объяснить, что вы делаете и что Red Hat делает в этих обновлениях?

Алексей: Я думаю, что существует путаница вокруг того, что такое OpenJDK. Есть OpenJDK "проект" и OpenJDK "дистрибутив". Путаница в том, что в дистрибутиве нет золотого двоичного кода для OpenJDK. Сайт OpenJDK не содержит двоичных файлов, что означает, что для создания сборки вам придется полагаться на нижестоящие дистрибутивы. [Редактор: Red Hat начал публиковать ванильные сборки на https://adoptopenjdk.net/upstream.html через некоторое время после этого интервью.]

Во времена Sun/Oracle, это было обычное Sun/Oracle производство собственных нижестоящих дистрибутивов JDK на основе OpenJDK исходников. Недавно компания Oracle решила реализовать свои собственные разработки только при наличии коммерческой поддержки. Они также любезно публикуют сборки OpenJDK на своем сайте https://jdk.java.net/

Будучи поставщиком нижестоящих версий, как и все остальные, Oracle вольна выбирать, какие сборки публиковать. И на данный момент они предпочитают публиковать только последние сборки OpenJDK 12. Если вы хотите 11u или 8u от Oracle, вы должны пойти на их коммерческое предложение. Но это и есть часть Oracle, также существуют другие участники экосистемы, которые используют OpenJDK в качестве проекта, то есть репозитории исходных кодов, которые находятся в открытом доступе, и создают из них свои 8u и 11u бинарные файлы. Их много, включая, но не ограничиваясь ими, Red Hat, SAP, AdoptOpenJDK и т.д.

Теперь вопрос в том, что содержат эти бинарные файлы? На это есть два ответа. Во-первых, существуют репозитории с открытым исходным кодом для 8u и 11u, из которых вы можете создавать свои сборки. Во-вторых, некоторые производители предпочитают применять некоторые дополнительные патчи, поскольку, например, не могут дождаться появления патча, чтобы он появился в потоке, а затем предоставить его своим пользователям. Тем не менее, я полагаю, что существует внутреннее давление на процесс распространения этих патчей, поскольку это помогает сбалансировать нагрузку на работу над обновлениями.

Когда вы услышите новость о том, что Red Hat "принимает" права собственности на релизы 8u и 11u - это новость об Эндрю Хейли, который является официальным лидером проекта в этих проектах обновления OpenJDK. Речь идет скорее об официальной роли, которая делает Red Hat официально ответственным за эти исходные деревья и процессы вокруг них. Фактическая работа выходит за рамки этих формальностей. Если вы посмотрите, что там делается для текущей версии 8u212 и 11.0.3, вы увидите, что в то время как Red Hat выполняет значительную часть бэкпортных исправлений, есть и другие команды и другие компании, в частности SAP, которые очень активны. Другие производители, такие как Amazon и Google, также принимают активное участие в проекте.

Существует общая площадка, где поставщики могут сотрудничать в выпусках обновлений, а затем создавать их на основе вышестоящего репозитория. Так что их собственные бинарные файлы 8u и 11u обычно сходятся в OpenJDK. Некоторые могут захотеть изобразить его как бесплатные джунгли для всех, когда у вас несколько поставщиков и вы не знаете, какой поставщик что поставляет, но в действительности большинство поставщиков действительно работают через этот вышестоящий процесс 8u и 11u, и таким образом в основном соглашаются, какие они имеют исходники.

Думаю, это отвечает на вопрос о бесплатных обновлениях и бесплатных исправлениях ошибок. Исходные коды обновляются в рамках процесса обновления OpenJDK. Выберите производителя, который предоставляет вам бесплатные сборки (большинство из них) из тех исходников, и вы получите бесплатные обновления.

Ричард: Понятно. Таким образом, практическое значение для Java-разработчика заключается в том, что он все еще может использовать Java-приложение и запускать его на JVM разных производителей. И они вольны выбрать того, кто предложит лучший вариант поддержки по договору и процессу и тому подобное?

Алексей: Да, спецификация... Я имею в виду, есть обязательное тестирование, которое каждый релиз должен пройти под названием Java. Обычно поставщики проводят дополнительные тесты дополнительно к этому. Я надеялся на такой же уровень совместимости с другими версиями JDK.

Если вы очень внимательно посмотрите на списки исправлений, публикуемые производителями, или на то, как они описывают свое отклонение от вышестоящих версий, то эти исправления окажутся незначительными. Например, вещи, которые помогают им встраивать в свою среду, предоставляют дополнительные сертификаты CA или делают что-то другое, что не является исправлением совместимости. Некоторые из них являются исправлениями ошибок или производительности, которые уже находятся в процессе обновления, но еще не перенесены в ванильный исходный код, который вы можете собрать прямо сейчас.

Ричард: Интересно, интересно. Ну, это немного меняющаяся экосистема для разработчиков Java, и им нужно понять, как адаптироваться и куда лучше всего двигаться.

Алексей: Да, я имею в виду, для некоторых людей. Другие, как и многие люди, работающие под Linux, с незапамятных времен привыкли иметь бинарные файлы OpenJDK от своих дистрибутивов, поскольку это было для них самым простым решением. Дистрибутивы Linux обычно собирают OpenJDK для вас. Полагаю, это в основном культурный сдвиг. До этого, только пользователи Linux привыкли к тому, что это был необязательный шаг, чтобы скачать бинарный файл Oracle со своего сайта...

Ричард: Точно, да, вы можете просто воспользоваться пакетом дистрибутива.

Алексей: Да. Для всех остальных, посещение Oracle было первым выходом, верно? Например, если вам нужен Java на рабочем столе Windows. Итак, то, что мы видим сейчас, это переход от менталитета одного производителя к менталитету Linux, когда вы выбираете провайдера, который предоставляет вам дистрибутив для продукта, в таких условиях, которые вам нравятся: платформы, для которых они собираются, частота/ оперативность выпуска, структура поддержки и т.д. Если вы не доверяете ни одному из существующих поставщиков, вы даже можете собрать OpenJDK самостоятельно и запустить его.

Ричард: И как бы вы прокомментировали, например, существующие дистрибутивы Linux и степень предоставляемого ими тестирования совместимости? Я имею в виду, вы упомянули, что Red Hat, очевидно, имеет большой доступ к тестированию, и как вы думаете, все ли дистрибутивы этого добиваются?

Алексей: Я не знаю, что именно дистрибутивы делают, но большинство из них строятся из одних и тех же исходных деревьев. Так что, если вы являетесь пользователем дистрибутива, то, вероятно, в ваших интересах пойти и спросить их об этом. По словам Эндрю Хейли: если вы не можете доверять пакету, который собирает ваш дистрибутив, то, возможно, вам не стоит использовать этот дистрибутив в первую очередь.

Ричард: Возможно. Да.

Алексей: Итак, да, если у вас есть сомнения относительно того, какие продукты входят в дистрибутив вашей операционной системы, тогда идите и спросите разработчиков, что находится в нем. Я бы сказал, что поскольку существует общая база кода для большинства сборщиков OpenJDK, то даже если вы вообще не будете тестировать и просто опубликуете бинарный файл и позволите пользователям установить его, существует очень большая вероятность, что непроверенный выпуск не будет нарушен. Поставщики, которые проводят тестирование, будут исправлять ошибки и публиковать исправления в деревьях исходных кодов.

Ричард: Да.

Алексей: Недочеты могут появиться, если ваша инструментальная связка слегка отличается от любой другой, такие вещи случаются. Я бы сказал, что скорость Red Hat в основном была протестирована так: мы собираем OpenJDK в виде RPM, а затем тестируем его. Поэтому мы уверены, что созданные нами бинарные файлы на самом деле проходят все тесты. Я не думаю, что это уникальная ситуация. Я думаю, это то же самое предложение для любого поставщика бинарных файлов: вы собираете что-то, проверяете, что бинарные программы работают, а затем вы публикуете их...

Ричард: Ага.

Алексей: Так что спросите у своего поставщика. Различия должны быть незначительными.


На этом завершаем первую часть нашего интервью с Алексеем. Мы все еще готовим вторую часть, в которой речь пойдет о параллельных сборщиках мусора и Shenandoah в частности. Это будет в прямом эфире на следующей неделе, так что не забудьте.

Мы хотели бы поблагодарить Алексея за то, что он уделил нам немного времени и посидел с нами, чтобы поделиться своими мыслями.


Источник: раз, и еще ссылки на различные OpenJDK сборки со StackOverflow: два.