Представляем вам интервью с Саймоном Риттером — человеком, который работал над Java с самого начала и продолжает делать это в роли заместителя технического директора Azul — компании, работающей над виртуальной машиной Zing JVM и одним из лучших сборщиков мусора, C4 (Continuously Concurrent Compacting Collector).
- Целая жизнь вместе с Java;
- Как оставаться на острие прогресса и кодить, когда ты CTO;
- Лучшие и худшие фичи JDK;
- Участие в исполнительном комитете Java Community Process;
- Не страшно ли что-то сломать в глобальном масштабе;
- Переход на JDK 11/12;
- Цена поддержки собственного форка OpenJDK;
- С4 & Falcon vs Shenandoah & Graal;
- Нужен ли мощный сборщик в мире микросервисов;
- Судьба серверов приложений, Java EE / Jakarta EE и JavaFx;
- Путешествие в Россию и свежий доклад на JPoint.
ЛегендаСаймон — Саймон Риттер, Deputy CTO of Azul Systems;
Евгений — Евгений phillennium Трифонов, журналист в JUG.ru Group;
Олег — Олег olegchir Чирухин, журналист в JUG.ru Group;
Евгений: Не могли бы вы рассказать нам о своей карьере до того, как стали заместителем генерального директора Azul? В частности, мне интересно, как вы в своё время оказались в Sun Microsystems.
Саймон: У меня уже очень длинная карьера — я закончил университет в 1987 году. Поначалу я занимался UNIX в небольшой компании здесь, в Великобритании. Потом работал в том месте, где UNIX, собственно, был изобретён — в Bell Labs. Через четыре года Bell Labs были поглощены Novell, и я стал консультантом по UNIX в Novell. Двумя годами спустя та часть их бизнеса, которая относилась к UNIX, была куплена Santa Cruz Operations, и на этом этапе я решил, что хочу заняться чем-то другим. Поэтому в 1996 году я пришёл в Sun Microsystems. Буквально через две недели, в феврале 1996 года, был выпущен в свет JDK 1.0. Поначалу я работал над вещами, связанными с Solaris и UNIX, но быстро понял, что самое новое и интересное там — это Java. Я был разработчиком и консультантом, а в 1999 году стал IT-евангелистом, иначе говоря — Developer Advocate, и продолжаю заниматься этим уже 20 лет. В 2010 году Oracle купил Sun, и в течение следующих 5 лет я был руководителем команды евангелистов. В 2015 году Oracle решил, что ему больше не нужны Developer Advocates, и меня уволили. На тот момент самым разумным решением было прийти в Azul, что я и сделал. С тех пор я о своём решении не пожалел, потому что продолжаю делать то, что мне нравится больше всего — рассказывать людям про Java, путешествовать, встречаться с интересными людьми и пробовать новые технологии. Если не вдаваться в детали, то так выглядит моя карьера.
Евгений: Звучит впечатляюще. Из известных мне людей вы, наверное, единственный, кто участвовал в разработке Java начиная с версии 1.0. Мне интересно, как она выглядела в то время. Насколько я знаю, тогда её считали языком для микроволновок и тому подобного. Это правда?
Саймон: Сейчас действительно интересно вспомнить самое начало истории Java. Тогда разработчики ориентировались в основном на десктопные приложения, апплеты и вещи, которые можно запускать в браузере. Потом появилась идея сделать версию для мобильных телефонов, и возникла Java ME. С годами стала расти значимость Java Enterprise Edition. С ней можно было писать более сложные сайты с онлайн-корзинами и оплатой через кредитную карту.
В начальных версиях Java библиотеки были весьма ограниченными, и одним из наиболее важных изменений по мере роста проекта стало появление больших базовых библиотек. Я часто рассказываю об этой эволюции в своих презентациях. В JDK 1.0 разработчикам было доступно 211 публичных классов, а в rt.jar из JDK 8 насчитывается 4.5 тысячи публичных класса. Это одна из причин популярности Java: программисту не нужно самому писать ArrayList или Semaphore, а к базам данным легко подключаться через JDBC.
Евгений: Java, безусловно, отличный язык, но при развитии любого проекта такого размера неизбежны ошибки. Иногда можно услышать сожаления Java-разработчиков о том, что ту или иную фичу нужно было реализовать иначе. Есть ли у вас такого рода сожаления?
Саймон: Это непростой вопрос, но, наверное, здесь можно поговорить о политике обратной совместимости Sun и Oracle. Любое приложение на Java можно запустить с более поздней версией Java без перекомпиляции. Сам по себе этот подход вполне разумен: если приложение уже работает, не надо заставлять людей тратить на него дополнительные усилия. Но здесь важно не заходить слишком далеко. Вспомним, как были добавлены generics в Java SE 5. Обратную совместимость нельзя было соблюсти без type erasure, чтобы в classfile могли оставаться старые типы в виде raw types. Альтернативой этому были reified generics, с которыми параметры типа generics доступны во время выполнения приложения. Из моих разговоров с Брайаном Гётцом я знаю, что он не большой сторонник такого подхода, хотя, возможно, я не вполне правильно интерпретирую его слова. Так или иначе, я считаю, что это как раз та ситуация, в которой следовало пойти на некоторое нарушение обратной совместимости. Тогда generics можно было бы использовать более привычным способом.
Некоторые менее важные решения тоже, как мне кажется, были не совсем удачными. Мы начали убирать устаревшие API только в JDK 9 — думаю, это было слишком поздно. Следовало проводить контролируемые чистки с минимумом нарушения работы существующего кода. В общем, пару-тройку вещей действительно можно было сделать немного иначе. Но в целом разработчики Java, конечно, создали отличный язык.
Евгений: С вами многие согласны насчёт обратной совместимости и её ограничений. Java иногда считается чересчур консервативной.
Олег: Кстати говоря, если бы изменения в generics действительно были более радикальными, то потребовалось бы перекомпилировать или даже изменить все приложения в экосистеме за один день. Наверное, это было бы не самым разумным решением.
Саймон: По-моему, перекомпилировать код — не слишком суровое требование. Конечно, если оказывается необходимым внести какие-либо сложные изменения, то это совсем другое дело. Думаю, здесь можно спорить до бесконечности о том, какой подход лучше.
Олег: Наши подписчики знают о вас уже многое из интервью и выступлений на конференциях. Но о том, чем именно вы занимаетесь сейчас в Azul, известно мало. Не могли бы вы рассказать нам о своей нынешней деятельности?
Саймон: Название моей должности — заместитель генерального директора, но это не вполне точно описывает то, что я делаю. Как и раньше в Oracle и Sun, я объясняю людям, как именно им может помочь моя компания и Java в целом. Нужно сказать, что кроме Java Azul ничем больше не занимается. У нас есть Zulu OpenJDK и коммерческая Zing JVM с альтернативным способом сборки мусора и своим JIT-компилятором. В общем, я содействую распространению Java, отдавая предпочтение нашей версии, и с этой целью я часто выступаю на конференциях. Но в подходе Azul мне нравится, что они большое внимание уделяют продвижению Java в целом, а не только своего продукта. Благодаря этому я могу читать курсы про лямбда-выражения и стримы, рассказывать в своих выступлениях про новые фичи JDK 11, про то, как пользоваться локальным выводом типов и так далее.
Если говорить об отличиях от предыдущей деятельности, то, во-первых, сейчас я пишу значительно больше статей и постов, чем раньше. Во-вторых, я значительно больше общаюсь с клиентами. Но это в основном обсуждение технических вопросов — я помогаю им понять, как устроен Zing, сборщик мусора C4 или JIT-компилятор Falcon. Продажами я не занимаюсь.
Олег: Само собой разумеется, что вы не можете посвящать всё своё время программированию. Как вам удается поддерживать связь с миром разработки? Пишете ли вы вообще, читаете ли технические статьи?
Саймон: Безусловно, и для меня очень важно оставаться в курсе последних изменений. Мне очень помогает тот факт, что Azul входит в JCP, и я представляю Azul в исполнительном комитете. Там я общаюсь с другими представителями и вижу, в каком направлении развивается Java. Кроме того, я вхожу в экспертную группу Java SE по создаваемым JSR. Это тоже помогает разобраться в происходящих изменениях. Далее, Azul активно участвует в OpenJDK, что даёт мне дополнительную видимость. Помимо этого я читаю технические статьи и много общаюсь со знакомыми из Oracle, что позволяет мне получить представление о том, что происходит в компании.
И, конечно же, я пишу код, причём стараюсь делать это каждый день. Правда, это не всегда получается, но я считаю, что если общаешься с людьми о программировании, то нужно писать самому. Обычно я работаю над проектами с фичами, которые мы рассматриваем, например, с модулями. Какое-то время назад я написал пост про то, как использовать jlink для создания рантаймов приложений без модулей в приложении. Чтобы это сделать, мне, очевидно, потребовалось разобраться в jlink и самому использовать его в коде. Так что программирование по-прежнему занимает очень важное место в моей деятельности.
Олег: Давайте представим, что у вас есть суперсила, благодаря которой вы можете убрать одну фичу из Java и добавить любую другую. На чём бы вы остановили свой выбор?
Саймон: Это непростой вопрос. Проще сказать, какая фича моя любимая — это лямбда-выражения и потоки, благодаря которым можно писать в более функциональном стиле. С этой фичей Брайан Гетц, Стюарт Маркс и вся их команда проделали просто блестящую работу. Правда, некоторая критика здесь иногда тоже звучит, в особенности в адрес Optionals, но это уже детали.
Значительно сложнее сказать, что мне нравится меньше всего в Java. Мне кажется, обработка исключений устроена не самым простым образом. Споры о них и об их реализации в Java ведутся уже давно, и они действительно доставляют некоторые трудности. Например, если у вас бросается исключение в лямбда-выражении, то вы не можете его поймать за пределами стрима — а именно это обычно и стоит делать. Вам обязательно нужно поймать исключение внутри лямбда-выражения. Так что сами лямбды — моя любимая фича в Java, а обработка исключений в них, наоборот, вызывает больше всего негативных эмоций.
Олег: Вы упомянули исполнительный комитет JCP. Как именно протекает его деятельность? У вас есть своё здание для встреч, своего рода «Белый дом», как у настоящего правительства?
Саймон: (смеется) Думаю, мы больше похожи на комитет по стандартам. Мы проводим регулярные встречи, но чаще всего они проходят в форме телеконференций. Три или четыре раза в год мы собираемся в одном помещении и в течение дня или двух обсуждаем вещи вроде JSR. У нас нет постоянного офиса, все встречи организуются различными компаниями на добровольческой основе. В Великобритании их проводила IBM, в Болгарии — SAP, а в ближайшем будущем будет встреча в Японии, её организует Fujitsu. Эта система нам отлично подходит, и на самих мероприятиях обычно очень дружелюбная атмосфера. Конечно, у нас бывают и споры, но в целом в комитете отличные люди.
Олег: А вам, как члену экспертной группы, не страшно добавлять новые фичи? Ведь Java — очень сложная система, можно нечаянно всё сломать.
Саймон: За последние два-три года функционирование экспертной группы существенно изменилось. В свое время Sun сделали исходный код открытым и создали OpenJDK, сейчас он всё в большей степени направляет развитие Java в целом. Конкретные фичи предлагаются через JEP (JDK Enhancement Proposal). Иногда эти предложения поступают извне — от Azul, Red Hat, IBM и даже Google. Но контроль в конечном итоге всё равно принадлежит Oracle: они выполняют большую часть работы и определяют направление развития. Oracle принадлежит функция своего рода попечителей, стюардов языка. Благодаря им внесение новых фич происходит упорядоченно, они стараются не торопиться без нужды. Сейчас новая версия выходит каждые полгода, и я замечаю, что разработчики не боятся отложить фичу до следующего релиза, если она ещё не доведена до ума. Мне очень нравится такой ответственный подход. Прекрасный пример его — JDK 12, который выходит в следующем месяце. Изначально в него хотели включить string literals, но потом решили, что их нужно ещё доработать.
Мы с Саймоном гуляем по Java-конференции JBreak год назад
Олег: А вы и ваша компания уже перешли на Java 11 или 12?
Саймон: В своих проектах я часто использую Java 11, но это обычно код не для продакшна, он, скорее, экспериментальный. Из моих разговоров с разработчиками по всему миру у меня складывается впечатление, что люди постепенно переходят на JDK 11, потому что это релиз с долгосрочной поддержкой. Конечно, надо иметь в виду, что эта поддержка предоставляется сейчас на других условиях, чем раньше. За коммерческое использование теперь нужно платить. Есть компании, которые следуют тому же графику релизов, что и Oracle. Это Azul, AdoptOpenJDK, Amazon Coretto. Они рассчитывают на то, что JDK 11 будет иметь долгосрочную поддержку, а следующим долгосрочным релизом будет JDK 17. Как правило, люди не готовы переходить на новую версию каждые шесть месяцев, в особенности в продакшне. Возможно, это смогут делать стартапы, но большинству коммерческих пользователей нужна стабильность. По крайней мере, сейчас это так.
Олег: Кстати говоря, насколько мне известно, AdoptOpenJDK не используют тесты TCK. Поскольку тестирование всё равно необходимо, они предлагают другие подходы, о которых они рассказали на последней конференции FOSDEM, разные сумасшедшие штуки вроде машинного обучения. В числе этих подходов были радикальные вещи вроде машинного обучения. А у вас много усилий уходит на поддержание своего форка OpenJDK?
Саймон: На самом деле, это не так уж и сложно. Правда, нужно и время, и инфраструктура. В AdoptOpenJDK ее предоставляют различные спонсоры, в том числе Azul. Собрать свой собственный JDK достаточно легко, скрипты для сборки работают хорошо. В этом плане ситуация существенно изменилась по сравнению с тем, что было, когда OpenJDK только появился на свет. Далее вам необходимо определиться, нужно ли вам соответствовать стандарту Java SE. Для этого как раз и нужен TCK. Получить TCK от Oracle можно бесплатно, если вы просто хотите сделать свою сборку OpenJDK. Я точно не знаю, почему именно у AdoptOpenJDK нет лицензии TCK. Думаю, это связано с тем, что они параллельно собирают проект OpenJ9 для IBM. А проект может получить TCK только в том случае, если он в основном базируется на OpenJDK. Это моё предположение, но если вы хотите узнать наверняка, вам придётся спросить у самих разработчиков AdoptOpenJDK. Так или иначе, у них сейчас нет возможности удостовериться, что их проект соответствует стандарту Java SE. Поскольку код, на котором они основывались, является эталонной реализацией, скорее всего он этому стандарту отвечает, но точной уверенности без TCK у нас нет. Но у AdoptOpenJDK много других тестов, которые в основном проверяют, как на JDK запускаются приложения. То есть это высокоуровневое тестирование, а не просто проверка соответствия стандарту.
Олег: У Azul есть свой дистрибутив OpenJDK, Zulu. Не могли бы вы рассказать про него? Он опенсорсный? В чём разница между ним и всеми остальными?
Саймон: У Zulu есть две версии — Community Edition и Enterprise Edition. По большому счёту, здесь такой же подход, как и у Red Hat. Community Edition — открытая версия, её можно скачать с нашего сайта. Она распространяется под лицензией GPLv2 with Classpath Exception, т.е. той же, что и OpenJDK, поэтому ей можно пользоваться так, как вам заблагорассудится. Но у этой версии нет коммерческой поддержки. Zulu Enterprise Edition ориентирована на крупные организации, которым нужна платная поддержка продукта. Между этими версиями есть различие в том, как происходят обновления. Для Enterprise Edition мы делаем бэкпорты самостоятельно. Когда Oracle выпускает обновление для очередной версии JDK, скажем, 12 или 13, мы очень быстро делаем его доступным для 8, 7 и даже 6 версии Zulu Enterprise. В Community Edition мы просто берём исходный код OpenJDK и собираем его. Если фиксы уже есть в этом коде, то они будут и в Community Edition, если же бэкпортов никто другой не сделал, то и в Community Edition их не будет. По-моему, это здравый подход.
Олег: В последнее время у целого ряда компаний появились продукты, близкие к тому, что делает Azul. Например, сейчас есть несколько низкопаузных сборщиков мусора, а в Oracle Labs был создан JIT-компилятор Graal, аналогичный Falcon от Azul. Вы можете рассказать нам, что именно представляют из себя C4 и Falcon, и в чём их отличие от аналогичных продуктов других компаний?
Саймон: Давайте начнём со сборщиков мусора. C4 — сборщик мусора, который не делает остановок stop-the-world, в отличие от традиционных сборщиков мусора, скажем, CMS, G1 и так далее. Над C4 мы работали больше десяти лет. Сейчас он работает очень стабильно, и мы его много где используем. Но за это время действительно появилось несколько аналогичных сборщиков мусора от наших конкурентов. Один из таких сборщиков мусора — ZGC от Oracle, который недавно стал открытым и вошёл в состав OpenJDK. В ZGC много решений, схожих с теми, которые использует C4. Например, для доступа к объектам используется барьеры чтения, а не барьеры записи. Он работает почти так же хорошо, как и наш. Но проблема в том, что это опенсорсный проект, и Oracle не занимается его активной разработкой. Насколько мне известно, они не планируют включать его в свои коммерческие продукты, он скорее носит экспериментальный характер. До того, как он стал опенсорсным, над ним работало всего два программиста из Швеции. Так что здесь необходимо быть осторожным, поскольку не вполне понятно, насколько этот проект стабилен. Я общался с некоторыми людьми, которые пользовались ZGC, и, по их словам, он даёт неплохие результаты, но стабильность оставляет желать лучшего — по крайней мере, они не стали бы использовать его в коммерческом приложении.
Shenandoah — это сборщик мусора от Red Hat. Он ориентирован на приложения с большими кучами, минимум 20 гигабайт, в то время как у Zing минимальный размер кучи — один гигабайт. Shenandoah по-прежнему находится в разработке, и она продолжается уже продолжительное время. Над ним работают Christine Flood и Алексей Шипилёв, оба прекрасно разбираются в своём деле. Насколько я понимаю, Shenandoah сейчас использует кучу с одним поколением. Имеющиеся на сегодняшний день результаты свидетельствуют о том, что более успешным был бы традиционный подход, т.е. несколько поколений. Скорее всего, здесь ещё есть над чем поработать. Сейчас Shenandoah входит в состав OpenJDK 12 как экспериментальная фича, и это прекрасно, поскольку это даёт пользователям выбор. Из наших клиентов пока никто не перешёл на Shenandoah или ZGC. Возможно, кто-то захочет это сделать в будущем.
Что касается JIT-компиляторов, мы хотели улучшить код, который они генерируют, и поначалу ориентировались на компилятор C2. Но C2 уже больше 20 лет, и он написан довольно сложно, его трудно будет модифицировать. Мы также рассматривали LLVM, это опенсорсный проект, который занимается компиляторами. Мы взяли их исходный код и интегрировали его в JVM. LLVM в основном выполняет статическую AOT-компиляцию, у нас эта технология использовалась для JIT-компиляции. Поскольку мы добропорядочные участники опенсорсного сообщества, мы добавили эти изменения к проекту LLVM. У нас получилась очень элегантная модульная структура, благодаря которой легко добавлять новые фичи, так что можно вносить новые интринсики, новые модули и т.п. Кроме того, над LLVM сейчас работают люди из Intel, Sony, Microsoft, что, безусловно, сильно нам помогает. Каждый раз, когда мы обновляем наш исходный код, мы получаем улучшения в производительности, сделанные другими людьми.
Перейдём теперь к Graal. Это экспериментальный JIT-компилятор, написанный на Java, который задумывался как альтернатива для C2. В большинстве случаев Falcon даёт значительно лучшие результаты, чем Graal. Компилятор Graal — часть более крупного замысла, GraalVM. В ней пытаются найти альтернативный подход к тому, как запускаются приложения. Там будет не только Java, но и другие языки. В целом, меня радует, что в этом направлении ведётся много исследований и существует много альтернативных проектов. Думаю, никто не хочет, чтобы у нас остался только один способ сборки мусора или JIT-компиляции. У людей есть выбор, и это правильно.
Олег: Честно признаться, я не ожидал такого всеобъемлющего ответа. Спасибо! Сейчас делается много докладов про микросервисы, микро-инстансы в облачных средах, даже легковесные облачные функции. Четверть программы JPoint посвящена реактивным технологиям. Все больше людей советует создавать не крупные сервисы, а небольшие инстансы. Но для небольшого инстанса с маленькой кучей не нужен мощный сборщик мусора. Можно даже использовать сверхбыстрые сборщики мусора вроде того, который используется в Golang. Какое будущее у умных сборщиков мусора и умных JIT-компиляторов? Сохраняют ли они свою актуальность?
Саймон: Безусловно. Микросервисы — интересный термин, и, на мой взгляд, не вполне точный. Было бы правильнее называть их просто сервисами. Основной принцип микросервисов — специализация, для достижения которой большое монолитное приложение разбивается на ряд отдельных сервисов. Один такой сервис может выполнять транзакции по кредитным картам, другой обеспечивает работу корзины для онлайн-магазина, третий занимается хранением данных. Но здесь важно понять, что микросервис не обязательно должен быть маленьким. В качестве примера можно привести кластеры Cassandra. Такой кластер можно считать микросервисом — у него только одна задача, с которой он отлично справляется. Но при этом у них довольно внушительные размеры и большая куча. Несмотря на то, что они выполняют только одну задачу, они обрабатывают большие объемы данных.
Кроме того, я могу сказать по своему многолетнему опыту работы со многими проектами, что при разбиении приложения на части нужно быть осторожным. В итоге возникает больше проблем, чем при сохранении высокоуровневой архитектуры. Я как раз обсуждаю сейчас эту тему с моими клиентами, которые перешли на архитектуру микросервисов. Когда с приложением возникает проблема, в особенности связанная с производительностью, им оказывается тяжело определить, какой именно сервис её вызывает. Им теперь нужен анализ множества сервисов, запущенных во множестве различных мест. Они не могут просто запустить инструмент отслеживания производительности на своём приложении, им приходится отслеживать множество различных мест и просматривать сообщения, которыми обмениваются сервисы. Разобраться во взаимодействиях между микросервисами значительно сложнее, чем во взаимодействиях между частями одного приложения.
Действительно, сейчас есть тренд в сторону небольших микросервисов, которые запускаются очень быстро, требуют минимум ресурсов, небольшую кучу, и им хватает сборщика мусора Golang. В JDK 11 был добавлен сборщик мусора Epsilon, который не собирает мусор. Ход мысли здесь такой: если у нас бессерверные вычисления, все микросервисы запущены на облаке, и у них нет состояния, то сборка мусора и не нужна — разве это не прогресс? Безусловно, есть ситуации, в которых этот подход может работать, но значительной части реальных приложений всё равно будет нужна куча и сборка мусора. А значит, им будут нужны различные подходы к высокопроизводительной сборке мусора. В общем, микросервисы — это прекрасно, но с ними важно не зайти слишком далеко.
Олег: А как насчёт крупных серверов приложений, которые работают в качестве платформ для сервисов? Примерно две недели назад GlassFish стал частью Eclipse. Думаете ли вы, что это правильный путь развития?
Саймон: Мне кажется, что для разных приложений хороши разные подходы. Микросервисы сейчас определённо в моде, но я не знаю, насколько они будут жизнеспособны в долгосрочной перспективе. Тут есть много трудностей, которые, правда, преодолимы. Вопрос в том, сможем ли мы найти максимально простое решение для них. Kubernetes — отличное дополнение к микросервисам, он позволяет управлять ими и упрощает работу. Нам нужны решения именно такого характера.
Олег: Eclipse и Jakarta EE утверждают, что их главная фича — интеграция в облачной среде, т.е. Docker, Kubernetes и т.п. Какое место занимает Java в облачных технологиях? Жизнеспособна ли она там? Можно ли запустить Falcon на Arm64?
Саймон: Безусловно, если вы хотите запустить Falcon на другой архитектуре, вам придётся дополнительно поработать. Но здесь опять-таки нам помогает тот факт, что в LLVM участвуют многие крупные компании, в том числе ARM. Они знают свою архитектуру, и поэтому могут добиться отличной совместимости компилятора с ней. Благодаря этому преимуществу мы можем работать с различными облачными архитектурами, и мне не видится здесь никаких затруднений для нас.
Олег: Кстати говоря, Java Enterprise и JavaFX больше не входят в дистрибутив OpenJDK. Как вам кажется, это к лучшему или нет? И, в целом, какой ваш взгляд на будущее Java EE и JavaFX?
Саймон: C JavaFX ситуация проще, поэтому давайте начнём с неё. Если мне не изменяет память, JavaFX появилась аж в 2004 году. Это была интересная попытка предоставить более совершенное средство разработки UI. Я написал довольно много кода на JavaFX, и она мне очень нравится. С ней значительно проще, чем со Swing и AWT, благодаря наличию поддержки style sheets, различных способов работы с layouts и так далее. Тем не менее, JavaFX так и не стала частью стандарта Java SE, как этого многие хотели. Oracle решили, что больше не будут вкладываться в этот проект, и открыли исходники для него. Но большой проблемы в том, что они не включают его в JDK, на мой взгляд нету. При желании вы вполне можете пользоваться JavaFX, как это делает, скажем, Gluon. Azul может предоставлять поддержку JavaFX как часть поддержки Zulu. В общем, здесь всё просто.
Что касается Java EE, то, как мы знаем, в JDK 11 был удалён модуль java.se.ee — это агрегатор, включающий в себя шесть других модулей. В их числе JAX-B и CORBA, её из известных мне людей не использует сейчас никто, так что это не страшно. А вот удаление JAX-WS не всеми было хорошо воспринято. Но, опять-таки, благодаря наличию модульной системы сейчас относительно несложно получить опенсорсную версию необходимого вам модуля, если он был удалён из JDK. Поддержка для этого есть в т. ч. на Maven Central. Поэтому я считаю, что со стороны Oracle было правильным решением почистить Java. Я уже говорил, что в прошлом, наверное, следовало более активно избавляться от устаревших модулей. Java уже 24 года, и нам нужно активнее удалять старые фичи, которыми люди уже не пользуются. Это также упростит жизнь разработчикам OpenJDK, поскольку уменьшится количество кода, которое нужно поддерживать. Короче говоря, я считаю, что этот подход правильный.
Олег: Последний вопрос, будете ли вы на JPoint, и если да, то как дела с российской визой? Было ли тяжело её получить?
Саймон: Да, я с нетерпением жду JPoint. В прошлом году я был на конференции JBreak в Новосибирске, и остался очень доволен этой поездкой в Сибирь. Конференция была отличная, в ней участвовало много интересных людей. В Москве я уже был несколько раз, и она произвела на меня большое впечатление, так что я рад буду туда вернуться.
А вот с визой действительно ситуация непростая. Недавно я разбирался с документами, необходимыми для её получения. В одном из пунктов анкеты, которую нужно было заполнить для подачи заявления, нужно было перечислить все поездки за границу за последние 10 лет, а также причину каждого визита. Мне на это было непросто ответить. К счастью, в графе ответа было всего 10 свободных ячеек, и я просто вписал туда свои последние поездки, места хватило где-то до ноября прошлого года. Кроме того, мне нужно было сдать отпечатки пальцев, чем я, собственно, и занимался сегодня утром, и из-за этого опоздал на интервью с вами. Но к следующей среде я уже должен получить визу, и тогда я буду готов ехать.
На самом деле, всё было не так уж и страшно. Я подавал заявление через специальную компанию, так что мне нужно было только заполнить анкету, дать им фотографию и отпечатки пальцев. Это существенно облегчило процесс.
Олег: А чему будет посвящён ваш доклад на конференции?
Саймон: Я буду рассказывать о том, что Java с новым графиком релизов стала развиваться быстрее, но при этом более мелкими шагами. Речь пойдёт о версиях с 9 по 12, а также о замыслах на будущее. В числе этих замыслов — проект Valhalla с его value types и reified generics, а также проект Loom с его fibers. Loom позволит сделать треды более легковесными и позволит привязывать множество файберов к одному треду операционной системы. Это улучит производительность приложений. Также я расскажу о проекте Amber, который позволит почистить синтаксис Java и сделать его менее многословным. В общем, это будет краткий обзор существующих и планируемых фич.
Думаю, с новым графиком релизов стало особенно важно следить за последними наработками. Правда, пользователи, скорее всего, будут переходить с одного LTS релиза на другой. Но за небольшими изменениями между ними следить всё равно стоит, потому что они могут повлиять на совместимость приложений, когда переход на новую версию всё-таки будет сделан. Если вы будете в курсе изменений, то вас не застанет врасплох этот переход. Даже если вы не развёртываете каждый новый релиз, тестировать его всё равно стоит, чтобы убедиться, что всё работает.
Саймон говорит о своих свежих докладах на JPoint 2019: «JDK 12: Pitfalls for the unwary» и «Local variable type inference: Friend or foe?». Да, целых два. Также в программе заявлены доклады от команды GraalVM (Thomas Wuerthinger и Олег Шелаев), Liberica JDK (Дмитрий Чуйко), Excelsior JET (Никита Липский), и т.п. JPoint 2019 пройдёт 5-6 апреля, с первого апреля билеты подорожают.
