Хабрахабр

Ударим Java EE автопробегом по бездорожью и разгильдяйству! Интервью с Себастианом Дашнером, коммитером Jakarta EE

Вкратце, кто это такой: Сегодня в нашей виртуальной студии Себастиан Дашнер.

В этом интервью мы поговорим на следующие темы:

Скрытый текст

  • Обычное приветствие: как ему понравилось в России и Сибири, JUG-путешествие на байках;
  • Чем занимаются Developer Advocates и не бездельники ли они;
  • Каким боком IBM относится к опенсорсу;
  • Поддержание продуктивности разработчика (со ссылкой на YouTube Себастиана);
  • Текущая ситуация вокруг Java EE и Jakarta EE;
  • Нужно ли мерджить Java EE и Jakarta EE;
  • Мнение по поводу Eclipse Specification Process;
  • Рассказ о IBM WebSphere Liberty Profile, отличиях от Full Profile и связи с реальным продом;
  • Отношение к проекту Helidon и что насчёт «выбросить Java EE и переписать заново»;
  • Поддержка облачных технологий в Java: Kubernetes, Istio;
  • Последний вопрос: Linux на десктопе.

Ведут интервью, как всегда, Евгений Трифонов (phillennium ), и Олег Чирухин (olegchir) из JUG.ru Group.

В вашем Твиттере я видел фотографию вас в Новосибирске в толстовке «ДЖАВА». Евгений: Начнём с нетехнического вопроса. Какое у вас осталось впечатление от этой поездки?

Конференция JBreak мне определённо запомнилась. Себастиан: Рад, что вы узнали фотографию, эта толстовка у меня с Joker 2017. Кроме того, за день до конференции я отмечал свой день рождения, и мы отправились кататься на снегоходах, после чего посидели в бане и поели шашлыки. Я никогда бы не предположил, что отправлюсь в такой далёкий уголок Сибири — думаю, из моего круга общения я один из немногих, кто там побывал. Природа вокруг Новосибирска очень красивая. В общем, осталось много приятных воспоминаний. И производит большое впечатление тот факт, что, если посчитать ещё и Красноярск с Томском, на тысячу километров вокруг тебя нет других крупных городов.

Это не совсем обычная позиция — другие знакомые мне Developer Advocates, как правило, занимаются продвижением продуктов своей компании. Евгений: Вы — Java Developer Advocate в IBM. Вы добиваетесь всеми возможными способами максимального распространения и эффективного использования Java? Какие именно у вас обязанности в IBM?

Надо добавить, что я в первую очередь выступаю в интересах не столько компании или продукта, сколько разработчиков. Себастиан: Да, это довольно точное описание того, чем я занимаюсь. Делюсь своими знаниями в блогах, подкастах, на семинарах и конференциях. Стремлюсь облегчить их работу и учу вещам, так или иначе связанным с Java Enterprise. Я не продаю какие-то отдельные продукты, скорее я продаю технологию в целом.

При этом мне известно, что IBM иногда принимает довольно активное участие во многих опенсорсных проектах, например, в OpenJ9. Евгений: Вы — большой сторонник опенсорса, но работаете в IBM, который у большинства людей с опенсорсом не ассоциируется. Как IBM относится к опенсорсу?

Например, IBM ведёт много работы в Cloud Native и в Java и является одним из главных участников в Kubernetes и Istio. Себастиан: Вы правильно заметили, что многие часто недооценивают участие IBM в опенсорсных проектах — я сам не имел об этом представления, пока не начал работать в этой компании. Эта компания также содействовала развитию serverless-технологий, например, Apache OpenWhisk. Доступ к исходникам OpenJ9 был открыт Eclipse Foundation, которая, в свою очередь, была создана IBM. Пока что люди действительно недостаточно знакомы с усилиями IBM в этом направлении, и моя работа как Developer Advocate заключается, помимо прочего, в том, чтобы информировать об этом сообщество. В целом, программисты в IBM очень дружелюбно настроены к опенсорсу — практически всё, что сейчас делается в этой компании, имеет опенсорсный аспект или открытую версию.

JUG на мотоциклах, whaaaat? Олег: Недавно прочитал в твиттере, что вы отправились в особое JUG-путешествие на мотоциклах по Японии вместе со Стивом Чином (Steve Chin). Можно подробней об этом?

Мы со Стивом Чином уже несколько раз путешествовали на мотоциклах, и каждый раз мы стараемся совместить это с выступлениями на конференциях и в юзер-группах. Себастиан: Это была отличная поездка. На первый взгляд может показаться, что мы это делаем только для развлечения — и, конечно, нельзя отрицать, что мы отлично проводим время в этих поездках. Несколько таких путешествий было в Германии, и три — в Японии. В каждой из этих поездок мы старались встретиться с максимальным количеством людей и поделиться с ними своими знаниями. Но и с чисто практической точки зрения мотоцикл — очень удобный вид транспорта для Японии или Центральной Европы, потому что там города с юзер-группами и айтишным сообществом находятся всего в сотне-другой километров друг от друга, и на мотоцикле можно избежать пробок.

Существует мнение, что Developer Advocate — несерьёзное занятие. Олег: Вы много путешествуете и даже ездили в Россию, хоть нашу визу получить не так-то просто. Считаете ли вы, что у вас настоящая тяжелая работа? Будто бы вы разъезжаете по всему свету, развлекаетесь на конференциях — что угодно, лишь бы не писать код. Кажется, каждый день летать на самолёте должно быть изнурительно.

Мне нравится моя работа, но при этом она далеко не всегда простая. Себастиан: Думаю, тут обе точки зрения немного правы. Действительно, поездки могут выматывать, в особенности если непосредственно после переезда вы не отдыхаете, а выступаете на конференции или организуете семинар. Одно никак не мешает другому. С другой стороны, если бы эта деятельность не увлекала, то от такого ритма очень быстро поехала бы крыша, и человек бы просто выгорел. А сразу после конференции нужно снова садиться в самолёт, так что день оказывается занят целиком. В общем, если мне за день удаётся научить людей чему-то и провести удачный семинар, то даже усталость становится приятной.

Из-за дополнительных нагрузок для Developer Advocates это тяжелее, чем для тех, кто постоянно программирует. Евгений: Насколько мне известно, эта работа требует большого количества усилий для того, чтобы оставаться в курсе новейших технологий в области. Трудно ли одновременно быть Developer Advocate и разработчиком? Я знаю, что вы регулярно пишете код для Jakarta EE, так что вы, очевидно, не оторвались от технологии.

Чтобы говорить о технологии со знанием дела, нужен постоянный опыт работы с ней. Себастиан: Да, безусловно, для моей работы очень важно оставаться программистом, иначе потеряешь связь с реальностью. Кроме того, нужно, чтобы вас по-настоящему увлекала техническая сторона дела и вы готовы были бы тратить на неё вечера и выходные. И времени на программирование действительно остаётся значительно меньше из-за конференций. В общем, нужен определённый баланс между обеими сторонами деятельности.

На первой странице вашего блога есть эпиграф: Олег: Давайте перейдём к техническим вопросам.

IT should be simple and productive.
IT should solve problems, not create ones.
I believe that IT is a chance, not a cost factor.

Есть ли какие-нибудь советы относительно того, как быть более продуктивным, лайфхаки, конкретные технически ништяки и утилиты вроде jcmd или sdkman, что угодно? Какие, на ваш взгляд, самые важные факторы, определяющие продуктивность Java-разработчика?

Что касается простоты, то речь идёт о том, что нужно стремиться избавляться от излишней сложности как в инструментах, которые мы разрабатываем, так и в реализациях, где мы эти инструменты используем. Себастиан: Да, таких программ много. Всегда нужно спрашивать себя: станет ли мир лучше от этой фичи? Зачастую разработчиков привлекает сложность сама по себе, в продукт добавляются всё новые фичи исключительно из спортивного интереса. Приблизит ли она нас к завершению работы над продуктом? Поможет ли она решить какую-либо проблему?

Загуглите моё имя и фразу «developer productivity». Если говорить о продуктивности самого разработчика, я действительно могу порекомендовать ресурсы для этого. Там рассказывается про использование командной строки, горячих клавиш, про то, как пользоваться клавиатурой. Я записал видеокурс, который выложен на Youtube, и там я даю советы как раз по этой теме. И если вы станете вникать в эту тему, то сам процесс автоматизации и оптимизации работы станет затягивать. Общий смысл — как сделать больше работы в меньший промежуток времени. В общем, производительность программирования — очень близкая мне тема. Вы станете больше времени продумывать решение проблемы и меньше — тупо стучать по клавишам.

Расскажите, пожалуйста, что сейчас происходит вокруг Java EE и Jakarta? Олег: Насколько понимаю, вы коммитер в MicroProfile, и поэтому можете знать всё, связанное с ним. Я немного читал об этом, но для меня, как человека из мира Spring, всё это слишком запутанно.

Это довольно сложный процесс, и он ещё не завершён, так что разработчики пока не могут пользоваться Jakarta EE. Себастиан: Как вы, наверное, знаете, Jakarta EE — наследница Java EE, которую сейчас переводят в Eclipse Foundation. Конечно, в будущем Jakarta EE будет продолжать развиваться подобно тому, как Java EE развивалась в рамках JCP (Java Community Process). Однако в основе всё равно лежат стандарты Java EE, исходной точкой будет Java EE 8. Это значит, что сообщество из нескольких компаний, корпораций и отдельных разработчиков будет совместно вырабатывать стандарты для новой enterprise-версии Java.

Его создали несколько вендоров, у которых работают сервера Java EE. Из-за этих изменений в Java EE и возник MicroProfile. Мне кажется очень интересным тот факт, что MicroProfile старается восполнить недостатки Java ЕЕ в том, что касается современных cloud-native микросервисов. Цель здесь — обеспечить более быстрое развитие технологии, меньше завязанное на жёсткие стандарты. MicroProfile даёт доступ ко всем этим вещам, так что вам нет необходимости реализовывать их все самостоятельно. Например, в Java EE пока что нет систем для injectable configuration, fault-tolerance, мониторинга, всяких OpenTracing и тому подобного. В качестве основы берутся стандарты Java EE (например, JAX-RS и CDI), с которыми большинство JavaEE-разработчиков уже знакомы. При этом почти во всех случаях соблюдается совместимость с Java EE. Эти две экосистемы очень хорошо сочетаются друг с другом. Поэтому когда мне в моём приложении Java EE оказывается необходима fault tolerance, например, я не пишу всё это вручную, а интегрирую MicroProfile с моим приложением. Всё, что остаётся сделать в этом случае — включить определённые фичи в рантайм, а затем добавить необходимые проекты MicroProfile в приложение Java EE. У многих приложений, таких как Open Liberty или Payara, рантаймы поддерживают и MicroProfile, и Java EE. Пока мы ждём окончательного перехода Java EE в Eclipse Foundation, можно пользоваться этим решением.

Олег: Считаете ли вы, что MicroProfile нужно сделать частью Jakarta?

Лично я считаю, что MicroProfile лучше всего работает как своего рода инкубатор для Jakarta EE. Себастиан: Это отличный вопрос, и окончательного решения по нему пока что нет. Когда она достигает зрелости, те её элементы, которые хорошо себя зарекомендовали, становятся полноценными стандартами. Новый стандарт вначале добавляется в MicroProfile (как это было сделано с OpenTracing или injectable configuration), а затем мы смотрим, как система себя ведёт в продакшне. Таким образом, мы избавляемся от некоторой неопределённости, поскольку уже знаем, хорошо система работает в продакшне или нет.

Похожим адским клубком выглядели документы с черновиками спецификаций Jakarta EE. Олег: Раз уж речь зашла о стандартах, я видел Eclipse Specification Processes, это был огромный гуглодок, в котором было очень сложно разобраться. Например, чем это отличается от Java Community Process? Не могли бы вы помочь этот клубок размотать?

В данный момент мы пытаемся определить форму тех процессов, в соответствии с которыми Jakarta EE будет развиваться в будущем. Себастиан: Eclipse Foundation — опенсорсная организация. Я считаю, что эта модель очень хорошо себя показала. Вы упомянули JCP — так вот, я полностью согласен с мнением, что стандарты для Jakarta EE должны быть сделаны по образцу JCP. В этом процессе участвует несколько компаний с более или менее одинаковыми правами, так что он не застрянет в развитии, если одна из них окажется не в состоянии больше в нём участвовать. При этом нужно иметь в виду, что ни у одной компании нет монополии на разработку стандартов для Jakarta EE. Я считаю это важным преимуществом, поскольку эта технология очень важная, и её безопаснее разрабатывать в открытом сообществе.

Пользуетесь ли вы Technology Compatibility Kits для Java и Jakarta? Олег: Такую сложную технологию необходимо на чём-то тестировать. Или у вас свой набор тестов?

В JCP все эти TCK обычно имели закрытые исходники. Себастиан: Это тоже очень важная тема. С одной стороны, спецификация могла предоставить тесты, которые показывали, являлась ли некоторая реализация допустимой или нет. Это было довольно сомнительным преимуществом. Сейчас TCK стали опенсорсными. Но обычный разработчик не знал, что именно было протестировано там внутри, какое было покрытие у этих тестов и т.п. Если оказывается, что продукт какой-либо компании не работает так, как заявлено в спецификации, то можно не только указать на это компании, но и оставить заявку в самом TCK. В их разработке и улучшении могут теперь участвовать все компании и разработчики. Так вы улучшите не только софт одного поставщика, но и всю экосистему. Или ещё лучше, можно отправить несколько pull-requests и улучшить сам TCK.

Коль скоро вы работаете IBM, можете рассказать нам, что это такое и в чём отличие от Open Liberty? Олег: Есть ещё один продукт, у которого в имени присутствует слово «Profile»: IBM WebSphere Liberty Profile.

Это сервер приложений Java EE, для которого IBM предоставляет коммерческую поддержку. Себастиан: WebSphere Liberty Profile — коммерческая версия Open Liberty. Благодаря этому у enterprise-разработчиков есть теперь бесплатный и опробованный в продакшне сервер приложений. Я могу ошибаться, но, по-моему, Open Liberty стала опенсорсной полтора года назад. На дворе 2019 год, и я считаю, что сейчас каждая компания должна предоставлять опенсорсную версию своего продукта, чтобы у разработчиков была возможность бесплатно опробовать продукт. Если же компании нужна коммерческая поддержка или некоторые коммерческие фичи, она может воспользоваться WebSphere Liberty Profile. Опенсорс очень важен, и я рад, что у IBM теперь есть несколько вариантов бывшего WebSphere Liberty Server.

Вы не могли бы рассказать подробнее о том, как он устроен внутри? Олег: Я слышал, что он написан поверх OSGi.

Интересно, что там достаточно просто можно настроить, какие именно фичи будут включены. Себастиан: Я лично не занимался разработкой Open Liberty, но, насколько мне известно, под ним действительно лежит OSGi. Или можно сделать так, чтобы у вас было полноценное приложение Java EE. Если вы хотите использовать только MicroProfile, который охватывает лишь небольшое количество стандартов Java EE, то вы можете настроить систему соответствующим образом. Благодаря тому, что в запущенном инстансе включено только то, что действительно необходимо, достигается оптимальное время запуска и минимальное потребление ресурсов.

Используются ли одни и те же инструменты в обоих случаях? Олег: Отличается ли конфигурация и использование Liberty Profile от Full Profile?

В отношении выбора фич оба сервера можно настроить одинаково. Себастиан: Существенных отличий в использовании нет. Если у вас есть приложение Java EE или MicroProfile, настройка будет одинаковой для обоих типов.

А насколько оправдано использование Liberty Profile в крупных организациях? Олег: Компании уже давно используют Full Profile.

Даже если предприятие купило коммерческую поддержку, это не значит, что оно обязательно должно использовать Full Profile, вполне разумно использовать более легковесную версию. Себастиан: Абсолютно оправдано. К счастью, коммерческая поддержка и коммерческие фичи никак не связаны со старым миром WebSphere, так что сам по себе рантайм на удивление лёгкий и компактный, он запускается очень быстро, его можно развернуть за считанные секунды. Если в основе продукта корпорации лежат современные микросервисы и лёгкие рантаймы, то им может быть лучше выбрать именно WebSphere Liberty и настроить её так, чтобы она работала, скажем, только с MicroProfile. Независимо от того, пользуетесь ли вы коммерческими фичами, вы все равно имеете доступ к этому быстрому и современному рантайму. Так что если у вас есть современное приложение на основе Java EE, вы можете настроить свои фичи соответствующим образом и включить только те стандарты, которые действительно необходимы.

Насколько я знаю, он не использует ни один из существующих серверов приложений, он построен поверх своего собственного набора библиотек. Олег: В октябре Oracle выпустили Helidon — это легковесный фреймворк для микросервисов в Java. Поверх этой системы был даже реализован MicroProfile. Вместе они предоставляют основу для построения микросервисов — фичи для конфигурации, настроек безопасности, поднятия веб-сервера и так далее. Что вы об этом думаете? У меня сложилось впечатление, что разработчики Helidon считают, что в Java EE слишком много легаси, и её нужно выбросить и переписать заново.

Но, если честно, мне кажется наивным считать, что Java EE нужно целиком переписать. Себастиан: Helidon — очень интересный проект. Как правило, требуется выделенный набор фич / стандартов, чаще всего используемый в enterprise-приложениях. Действительно, большинству приложений не нужна Java EE целиком. Для этого нужны как минимум некоторые компоненты Java EE. Например, обычный MicroProfile пока что не предоставляет JPA или сложных сценариев для многопоточности. Опираясь на наиболее важные и современные компоненты Java EE, например, CDI, JPA, JAX-RS, JTA и так далее, мы выбираем нужный нам набор стандартов, при этом игнорируем множество унаследованных вещей, присутствующих в Java EE. В целом, процесс создания приложения мне сейчас видится таким образом. Если мы занимаемся чем-либо, связанным с cloud-native микросервисами, то добавляем к этому стандарты MicroProfile, например, fault tolerance. Исходя из этого выбора мы берём тот рантайм, который поддерживает все эти фичи. Я предпочёл бы рантайм, который поддерживал бы и Java EE/Jakarta EE, и Microprofile, и при этом давал бы возможность выбирать те фичи, которые нужны для конкретного приложения. Но рантайм вроде Helidon не поддерживает фичи, принадлежащие сугубо к Java EE, а между тем, многопоточность или JPA — фичи, которые, по моему опыту, весьма необходимы. В общем, у вас будет набор фич, очень похожий на MicroProfile, но при этом кое-что от Java EE тоже будет необходимо. Например, если вам нужен persistence и у вас есть база данных, вы можете включить JPA. Такого рода рантаймы — Open Liberty, Payara, WildFly и так далее.

А как сейчас обстоит дело с Java в контейнерах? Олег: Насколько я знаю, одна из наиболее интересных фич, которые будут в ближайшем будущем реализованы в Jakarta — поддержка современных облачных технологий. Можно ли сейчас, в 2019 году, использовать Java в контейнерах? Насколько я помню, несколько лет назад на багтрекере OpenJDK было несколько багов, связанных с совместимостью, размером хипа, сигналами и так далее.

Причиной большей части проблем, связанных с этим, была не собственно Java, а то, как работал Linux с контейнерами. Себастиан: Да, определённо можно. В последних версиях эти проблемы были решены. Зачастую контейнер просто не знал о различных ограничениях на ресурсы, которые можно было выставить. И если вы запросите размер памяти в системе или размер кучи по умолчанию, эти значения будут указаны верно. Теперь Java можно просто запустить в контейнере, и эти параметры будут включены по умолчанию. Java EE отлично работает в контейнерах Docker и, в целом, хорошо интегрируется с cloud-native технологиями.

Пользуетесь ли вы чем-то вроде Kubernetes или Istio? Олег: А как насчёт инфраструктуры?

Все мои приложения сейчас написаны на контейнерах Docker, для оркестрации контейнеров обычно используется Kubernetes, а для управления сервисами — Istio. Себастиан: Да, достаточно активно. Cloud-native технологии позволяют добавить множество необходимых фич поверх приложения, причём это делается прозрачно для приложения, ему не нужно заниматься вещами, связанными со средой — например, обнаружением сервисов, обеспечением видимости, мониторингом и т.п. Всё это прекрасно сочетается с подходом современной Java EE.

Будут ли у нас нативные API для этого? Олег: Что вы можете сказать о нативной интеграции Java EE с Kubernetes и прочей инфраструктурой?

И такой подход противоречил бы основному принципу cloud-native технологий. Себастиан: Настраивать Kubernetes или Istio изнутри приложения пока что нельзя. Приложение не должно знать, что оно запущено внутри контейнера Docker, который оркестрируется Kubernetes. Вся среда должна быть прозрачной для вашего приложения. А обнаружение сервисов и маршрутизация выполняется Kubernetes при помощи поиска DNS или при помощи Istio. Если речь идёт об обнаружении сервисов, приложение может найти и использовать логическое имя сервиса какого-то внешнего бэкенда просто как URL, как имя хоста. Я считаю такой подход правильным, потому что задача приложения — реализовывать бизнес-логику, а не заниматься вопросами среды. Этот процесс полностью прозрачен для вашего приложения.

Олег: Какое событие прошлого года из мира Java вам запомнилось больше всего?

Помимо этого, быстро развиваются современные enterprise-технологии — MicroProfile, cloud-native технологии (Istio, Kubernetes). Себастиан: Я даже затрудняюсь ответить — в Java сейчас происходит очень много изменений, резко выросла частота выхода новых версий. В общем, мы живём в очень интересное время. В прошлом году MicroProfile совершил огромный рывок вперёд, было выпущено множество новых версий.

Чему он будет посвящён? Олег: Вы собираетесь выступить на JPoint с докладом «Безотказные приложения на Java Enterprise».

Одно дело — просто реализовать бизнес-логику приложения; другое — запустить её в суровой и не прощающей ошибок среде продакшна. Себастиан: Я расскажу о том, что именно нужно иметь в виду enterprise-разработчикам, когда они запускают приложение в продакшне. Я буду говорить об устойчивости современного Java EE-приложения, о том, как в нём работают треды, как сделать приложение отзывчивым, как реализовывать и выполнять соглашения уровня сервисов.

В России я уже был, но в Москве — ещё ни разу. Я жду с нетерпением конференции JPoint. Я всегда рад пообщаться с активными Java-разработчиками, так что если у вас будет возможность к нам присоединиться — будет здорово.

В России на Хабре недавно было очередное активное обсуждение перспектив Линукса на десктопе (например, могло бы помочь появление одного «официального» дистрибутива). Евгений: Последний вопрос. Вы энтузиаст Linux, поэтому хочется спросить: что вы думаете об этом?

Я уже много лет пользуюсь Linux на десктопе, и я согласен с тем, что с ним может быть тяжелее справиться, чем с другими операционными системами, в особенности если у пользователя нет технических навыков. Себастиан: Отличный вопрос. На мой взгляд, правильным решением было бы предоставить выбор из различных фич и инструментов, которые поставлялись бы одной некоммерческой организацией. Вопрос в том, поможет ли делу создание единого официального дистрибутива, который было бы проще установить и которым было бы проще пользоваться. Я сейчас пользуюсь Arch Linux — там всё очень низкоуровневое, после установки система показывает тебе только командную строку. То есть это делалось бы не отдельной компанией, а сообществом, которое могло бы прийти к консенсусу относительно некоего базового варианта для разработчиков. Я не в восторге от Ubuntu и от их тяжеловесного UI, но такой дистрибутив значительно более доступен для новичков. Для большинства начинающих пользователей Linux жизнь с таким вариантом была бы слишком тяжёлой. Тем не менее, иметь некоторый разумный базовый вариант, наверное, было бы неплохо. Простого решения для этой проблемы я предложить не могу — по своей природе Linux устроен так, что в нём всё максимально настраиваемо, вы можете создать такую конфигурацию, которая подходит именно вам.

Олег: Спасибо большое за ответы!

Помимо него приедут также Simon Ritter, Kohsuke Kawaguchi, Андрей Паньгин и многие другие. Совсем скоро, 5-6 апреля, Себастиан выступит в Москве на JPoint с докладом «Bulletproof Java Enterprise applications for the hard production life». Здесь можно ознакомиться с программой.
С первого марта стоимость билетов увеличится.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть