В последнее время вокруг Java EE много шумихи: сначала выход восьмой версии, затем новость о переходе в Eclipse Foundation и о переименовании. Но многие обсуждения новостей сводятся к тому, что люди думают о новом названии EE4J. Мы решили этим не ограничиваться и расспросить Дмитрия Александрова (ведущего эксперта-программиста в T-Systems): он и имеет дело с Java EE в своей работе, и активен в EE-сообществе, и выступает с EE-докладами на конференциях. Так что вопросы мы ему задали и с точки зрения «применимость в вашей работе», и с точки зрения «что думает сообщество в целом», и заодно про доклады: он как раз уже завтра выступит у нас на Joker.
— Насколько Java EE 8 — масштабное и долгожданное событие для сообщества, и что из его нововведений вызывает наибольший резонанс?
— Я в целом согласен с официальной инфографикой от Оракула ниже:
Нынче огромный спрос на все, что связано с REST, HTTP/2 и JSON, и EE тут следует трендам. Необходимость в JSON-B была очевидна, и я думаю, что все крайне рады её появлению. Это очень облегчит всю разработку. Много внимания уделяется асинхронности/реактивности, плюс, естественно, секьюрити. Рассмотрение всех изменений потянет на целую статью, но, безусловно, релиз Java ЕЕ 8 был очень ожидаем. Сейчас это абсолютно современная платформа, предоставляющая всю инфраструктуру для современной энтерпрайзовой разработки.
— А что вы ощущаете в связи с собственной практической работой? Есть ли в «восьмёрке» то, что явно пригодится в проектах T-Systems? И как скоро в работе ощутите изменения?
— Под некоторые новые проекты нам точно нужно будет использовать стек MicroProfile + JSON-B, и, возможно, MVC. У нас много асинхронности и event-ов, и здесь ЕЕ 8 нам сильно упростит жизнь.
А про время — в таких крупных игроках, как T-Systems, подобные изменения ощущаются не сразу. У нас множество проектов, которым по несколько лет, и переход на новейшие платформы не всегда происходит моментально. Часто это довольно длительный процесс, связанный с множеством предварительных проверок и работ «в песочнице». Стабильность и безопасность превыше всего.
Тем не менее, мы всегда стремимся применять новейшие релизы, но не сломя голову, «потому что модно».
— Как оценивают в сообществе переход EE в Eclipse? В основном заметны одобрительные реплики, но встречаются и скептические вроде «Oracle избавляется от балласта» — что думают и в сообществе, и вы лично?
— Безусловно, это событие космического масштаба. Представьте себе — платформа 25 лет была под контролем всего одной корпорации, и тут эта огромная её часть откалывается от неё и уходит в самостоятельное плавание. ЕЕ столь массово распространена и комьюнити столь велико, что случившееся абсолютно естественно. Но я бы не стал называть это «избавлением от балласта». Тут следует только порадоваться, что она стала общественным достоянием.
На мой скромный взгляд, это рано или поздно должно было произойти. Но я не ожидал, что это произойдет столь скоро, и в данный момент наблюдаю за всем этим с интересом.
— В прошлом году сообщество жаловалось, что под управлением Oracle развитие EE шло медленно. Но не окажется ли теперь так, что без крыла Oracle он не ускорится, а ещё сильнее замедлится, и мы все ещё попросим Oracle вернуть всё обратно? :)
— Определённо нет. Я уверен, данное событие лишь подстегнёт более бурное развитие данной платформы для нужд индустрии. Более того, ЕЕ станет ещё более универсальной и портируемой, так как в этом заинтересованы основные вендоры — разработчики серверов. Теперь им будет проще самим сесть и договориться, как это стандартизовать. Хороший пример — MicroProfile. Несколько вендоров серверов просто сели и договорились, каким они хотят видеть этот субсет ЕЕ, проконсультировались с общественностью и воплотили. Сразу всплыли все недочёты, и комитет оперативно отреагировал. По мне так это просто замечательно!
— Про MicroProfile не все как следует знают. Раз вы уже уверены, что в T-Systems он пригодится — можете для пропустивших описать, что проект вообще представляет собой? И какие перспективы у MicroProfile теперь, когда его хотят переместить в EE4J?
— В двух словах, его появление обусловлено огромной популярностью микросервисов. Примечательно, что это абсолютно комьюнити-инициатива. Так вот, порой, чтобы поднять один REST endpoint, нужно было поднимать всю инфраструктуру EE — и персистенс, и JSF, и т.д. Сами понимаете, так быть не должно. И вот несколько вендоров ЕЕ-серверов собрались и решили: давайте выкинем все лишнее и оставим только JAX-RS, CDI, JSON-P. Этого в целом достаточно, чтобы запускать микросервисы (хотя это до сих пор подлежит дискуссии). Так и получился MicroProfile!
Сами дистрибуции серверов при этом становятся очень компактными, и часто упаковывается в 1 executable jar. Размеры таких fat jar редко больше 40 мегабайт. Я рад, что в болгарском JUG, ко-лидером которого я являюсь, мы активно участвуем в разработке MicroProfile, у нас есть активные коммитеры. Более того, мы сделали первый hands-on lab по данной теме, где мы по ходу воркшопа создаём web-приложение, состоящее из нескольких микросервисов, причём каждый микросервис идёт на своём сервере от своего вендора. И учитывая, что всё это единый стандарт, всё работает вместе замечательно! Довольно увлекательно!
Кстати, имя EE4J мне не нравится, но, уверен, там этой инициативе самое место!
— Была история с тем, что Oracle сначала выпилили проект MVC из Java EE и сообщество подхватило его как отдельную задачу, а теперь он вливается обратно в EE4J. Oracle отказывались по причине «никому не надо» — а по вашим ощущениям, насколько это актуально и востребовано? Виден ли спрос на это в сообществе и конкретно в вашей работе?
— Я бы сказал так: MVC — это хорошо. Очень хорошо само по себе наличие альтернативы JSF, потому что есть много задач, для которых JSF — это тяжело и слишком «стандартно». Более того эта модель отлично себя зарекомендовала в Spring. Пока что, судя по опросам и общему шуму, народ всё ещё не очень её принял в ЕЕ. Но, как я сказал выше, мы в T-Systems думаем применить MVC в одном из наших проектов.
— Сообщество Java EE Guardians вечно громко говорит обо всём, связанном с EE, но со стороны неочевидно: это действительно мощное сообщество единомышленников, или на самом деле это «Реза Рахман и ещё пара человек»?
— Реза, безусловно, один из столпов EE. Буквально недавно я был его ко-спикером на одной конференции, и мы как раз говорили о будущем ЕЕ. А Guardians далеко не пара человек. Вы взгляните на список их участников — начиная с Джеймса Гослинга, создателей ЕЕ-серверов, кучи JCP-экспертов, и заканчивая простыми «пользователями» ЕЕ. На самом деле «гардианы» одними из первых обратили внимание на застой в ЕЕ, начали движение по «развенчиванию» мифов о её тяжести, и способствовали эволюции платформы для соответствия новым потребностям индустрии.
— К вопросу о мифах. Сейчас есть настроения «кому вообще сейчас может быть нужна эта EE при расцвете Spring», она оказывается «немодной» — а как это выглядит с позиции человека, работающего с EE?
— На самом деле всё, что можно сделать на ЕЕ можно сделать на Spring. Более того, в Spring даже больше «сахара», так что для прототипирования или некой быстрой разработки, порой, он предпочтительней. Но тогда становишься «заложником» этого решения. Миграция на что-либо другое станет крайне сложна. В ЕЕ всегда есть альтернатива, на каком сервере всё будет работать. Более того, некоторые ЕЕ-вендоры предлагают абсолютно сопоставимый комплект «сахара».
Но если бы EE была «немодной», она не была бы столь распространена. Я всегда говорил: ЕЕ — это всё самое лучшее, что было когда-то придумано и внутри платформы, и на стороне. Это эссенция энтерпрайза, которая достойна быть стандартом.
— На прошлом Joker у нас вы делали доклад про JBatch из Java EE 7 — а сами его в работе применяете?
— Мы его применяли дважды, и это нам сэкономило много лишних усилий, так как подход максимально стандартен.
— К чему это спросили: хотя JBatch вроде как многим должен экономить усилия, его упоминания можно встретить очень редко. Почему так происходит? Люди по инерции делают велосипеды, даже когда это уже не требуется?
— Да, я сам называю JBatch «забытым API». Но я продолжаю видеть, как люди, как сказано выше, изобретают велосипеды. Очень многие считают задачу настолько простой, что зачем вообще думать? Написал пару циклов и в продакшн. А далее вы сами знаете, что следует. А когда приходится писать и параллельный код, всё становится максимально печально. Но если задача кажется чуть сложнее, то, естественно, принято брать что-то из хайпового, что часто приводит к излишним сложностям. Что касается недостатков JBatch, основной — это его неизвестность. Понятно, что это не идеальный инструмент, но, при подходящей постановке задачи, время он экономит здорово. Более того, знание о наличии подобного API поможет при дизайне архитектуры конкретного приложения.
— Напоследок немного отойдём от темы EE: на предстоящем Joker у вас будет доклад «Java и GPU», а о таком, как и о JBatch, говорят редко. Эта нетипичная тема тоже на основе личного опыта?
— Вы заметили, что я люблю рассказывать про всякую экзотику? GPU как таковым я увлекаюсь уже несколько лет, и, да, рассказывать буду исходя из личного опыта, хотя примеры будут более общего порядка. Прямой опыт применения был на моей предыдущей работе, где необходимо было быстро считать много heatmap-ов. А сейчас в нашей инновационной группе в T-Systems мы рассматриваем возможность применения GPU и для наших нужд, в том числе и в облаках. Я не считаю, что это должно применяться массово, так как сама «природа» вычислений на видеокартах ограничивает скоуп применения их повсеместно.
— Окей, это не для всех. А есть ли ощущение, что и те, кому сейчас было бы полезно использовать GPU с Java, сейчас этого зачастую не делают?
— На мой взгляд, GPU нынче особенно ценится на фоне бурного роста криптовалют и всего, что связанно с блокчейном. Java же очень неплохо представлена в финансах и банкинге. По сути, она там доминирует. Но есть и множество других задач в этой области, которые подходят под класс массовопараллельных — идеально подходящих для GPU. Более того, уверен, программистам будет интересно и полезно уметь общаться с GPU в принципе. В наши дни, на мой скромный взгляд, разработчику и архитектору просто необходимa способность определять, насколько конкретная задача распараллеливается, и на основе этого имплементировать её на самом подходящем устройстве. Лично я если увижу, что задача подходящая, естественно, буду стараться применить GPU. Тем более, что этот ресурс сейчас всё более доступен.
— Спасибо, будем ждать на Joker и вас, и T-Systems.
