Главная » Хабрахабр » Прошлое и будущее Java в интервью с Саймоном Риттером из Azul

Прошлое и будущее Java в интервью с Саймоном Риттером из Azul

Представляем вам интервью с Саймоном Риттером — человеком, который работал над 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;

В частности, мне интересно, как вы в своё время оказались в Sun Microsystems. Евгений: Не могли бы вы рассказать нам о своей карьере до того, как стали заместителем генерального директора Azul?

Поначалу я занимался UNIX в небольшой компании здесь, в Великобритании. Саймон: У меня уже очень длинная карьера — я закончил университет в 1987 году. Через четыре года Bell Labs были поглощены Novell, и я стал консультантом по UNIX в Novell. Потом работал в том месте, где UNIX, собственно, был изобретён — в Bell Labs. Поэтому в 1996 году я пришёл в Sun Microsystems. Двумя годами спустя та часть их бизнеса, которая относилась к UNIX, была куплена Santa Cruz Operations, и на этом этапе я решил, что хочу заняться чем-то другим. 0. Буквально через две недели, в феврале 1996 года, был выпущен в свет JDK 1. Я был разработчиком и консультантом, а в 1999 году стал IT-евангелистом, иначе говоря — Developer Advocate, и продолжаю заниматься этим уже 20 лет. Поначалу я работал над вещами, связанными с Solaris и UNIX, но быстро понял, что самое новое и интересное там — это Java. В 2015 году Oracle решил, что ему больше не нужны Developer Advocates, и меня уволили. В 2010 году Oracle купил Sun, и в течение следующих 5 лет я был руководителем команды евангелистов. С тех пор я о своём решении не пожалел, потому что продолжаю делать то, что мне нравится больше всего — рассказывать людям про Java, путешествовать, встречаться с интересными людьми и пробовать новые технологии. На тот момент самым разумным решением было прийти в Azul, что я и сделал. Если не вдаваться в детали, то так выглядит моя карьера.

Из известных мне людей вы, наверное, единственный, кто участвовал в разработке Java начиная с версии 1. Евгений: Звучит впечатляюще. Мне интересно, как она выглядела в то время. 0. Это правда? Насколько я знаю, тогда её считали языком для микроволновок и тому подобного.

Тогда разработчики ориентировались в основном на десктопные приложения, апплеты и вещи, которые можно запускать в браузере. Саймон: Сейчас действительно интересно вспомнить самое начало истории Java. С годами стала расти значимость Java Enterprise Edition. Потом появилась идея сделать версию для мобильных телефонов, и возникла Java ME. С ней можно было писать более сложные сайты с онлайн-корзинами и оплатой через кредитную карту.

Я часто рассказываю об этой эволюции в своих презентациях. В начальных версиях Java библиотеки были весьма ограниченными, и одним из наиболее важных изменений по мере роста проекта стало появление больших базовых библиотек. 0 разработчикам было доступно 211 публичных классов, а в rt.jar из JDK 8 насчитывается 4. В JDK 1. Это одна из причин популярности Java: программисту не нужно самому писать ArrayList или Semaphore, а к базам данным легко подключаться через JDBC. 5 тысячи публичных класса.

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

Любое приложение на Java можно запустить с более поздней версией Java без перекомпиляции. Саймон: Это непростой вопрос, но, наверное, здесь можно поговорить о политике обратной совместимости Sun и Oracle. Но здесь важно не заходить слишком далеко. Сам по себе этот подход вполне разумен: если приложение уже работает, не надо заставлять людей тратить на него дополнительные усилия. Обратную совместимость нельзя было соблюсти без type erasure, чтобы в classfile могли оставаться старые типы в виде raw types. Вспомним, как были добавлены generics в Java SE 5. Из моих разговоров с Брайаном Гётцом я знаю, что он не большой сторонник такого подхода, хотя, возможно, я не вполне правильно интерпретирую его слова. Альтернативой этому были reified generics, с которыми параметры типа generics доступны во время выполнения приложения. Тогда generics можно было бы использовать более привычным способом. Так или иначе, я считаю, что это как раз та ситуация, в которой следовало пойти на некоторое нарушение обратной совместимости.

Мы начали убирать устаревшие API только в JDK 9 — думаю, это было слишком поздно. Некоторые менее важные решения тоже, как мне кажется, были не совсем удачными. В общем, пару-тройку вещей действительно можно было сделать немного иначе. Следовало проводить контролируемые чистки с минимумом нарушения работы существующего кода. Но в целом разработчики Java, конечно, создали отличный язык.

Java иногда считается чересчур консервативной. Евгений: С вами многие согласны насчёт обратной совместимости и её ограничений.

Наверное, это было бы не самым разумным решением. Олег: Кстати говоря, если бы изменения в generics действительно были более радикальными, то потребовалось бы перекомпилировать или даже изменить все приложения в экосистеме за один день.

Конечно, если оказывается необходимым внести какие-либо сложные изменения, то это совсем другое дело. Саймон: По-моему, перекомпилировать код — не слишком суровое требование. Думаю, здесь можно спорить до бесконечности о том, какой подход лучше.

Но о том, чем именно вы занимаетесь сейчас в Azul, известно мало. Олег: Наши подписчики знают о вас уже многое из интервью и выступлений на конференциях. Не могли бы вы рассказать нам о своей нынешней деятельности?

Как и раньше в Oracle и Sun, я объясняю людям, как именно им может помочь моя компания и Java в целом. Саймон: Название моей должности — заместитель генерального директора, но это не вполне точно описывает то, что я делаю. У нас есть Zulu OpenJDK и коммерческая Zing JVM с альтернативным способом сборки мусора и своим JIT-компилятором. Нужно сказать, что кроме Java Azul ничем больше не занимается. Но в подходе Azul мне нравится, что они большое внимание уделяют продвижению Java в целом, а не только своего продукта. В общем, я содействую распространению Java, отдавая предпочтение нашей версии, и с этой целью я часто выступаю на конференциях. Благодаря этому я могу читать курсы про лямбда-выражения и стримы, рассказывать в своих выступлениях про новые фичи JDK 11, про то, как пользоваться локальным выводом типов и так далее.

Во-вторых, я значительно больше общаюсь с клиентами. Если говорить об отличиях от предыдущей деятельности, то, во-первых, сейчас я пишу значительно больше статей и постов, чем раньше. Продажами я не занимаюсь. Но это в основном обсуждение технических вопросов — я помогаю им понять, как устроен Zing, сборщик мусора C4 или JIT-компилятор Falcon.

Как вам удается поддерживать связь с миром разработки? Олег: Само собой разумеется, что вы не можете посвящать всё своё время программированию. Пишете ли вы вообще, читаете ли технические статьи?

Мне очень помогает тот факт, что Azul входит в JCP, и я представляю Azul в исполнительном комитете. Саймон: Безусловно, и для меня очень важно оставаться в курсе последних изменений. Кроме того, я вхожу в экспертную группу Java SE по создаваемым JSR. Там я общаюсь с другими представителями и вижу, в каком направлении развивается Java. Далее, Azul активно участвует в OpenJDK, что даёт мне дополнительную видимость. Это тоже помогает разобраться в происходящих изменениях. Помимо этого я читаю технические статьи и много общаюсь со знакомыми из Oracle, что позволяет мне получить представление о том, что происходит в компании.

Правда, это не всегда получается, но я считаю, что если общаешься с людьми о программировании, то нужно писать самому. И, конечно же, я пишу код, причём стараюсь делать это каждый день. Какое-то время назад я написал пост про то, как использовать jlink для создания рантаймов приложений без модулей в приложении. Обычно я работаю над проектами с фичами, которые мы рассматриваем, например, с модулями. Так что программирование по-прежнему занимает очень важное место в моей деятельности. Чтобы это сделать, мне, очевидно, потребовалось разобраться в jlink и самому использовать его в коде.

На чём бы вы остановили свой выбор? Олег: Давайте представим, что у вас есть суперсила, благодаря которой вы можете убрать одну фичу из Java и добавить любую другую.

Проще сказать, какая фича моя любимая — это лямбда-выражения и потоки, благодаря которым можно писать в более функциональном стиле. Саймон: Это непростой вопрос. Правда, некоторая критика здесь иногда тоже звучит, в особенности в адрес Optionals, но это уже детали. С этой фичей Брайан Гетц, Стюарт Маркс и вся их команда проделали просто блестящую работу.

Мне кажется, обработка исключений устроена не самым простым образом. Значительно сложнее сказать, что мне нравится меньше всего в Java. Например, если у вас бросается исключение в лямбда-выражении, то вы не можете его поймать за пределами стрима — а именно это обычно и стоит делать. Споры о них и об их реализации в Java ведутся уже давно, и они действительно доставляют некоторые трудности. Так что сами лямбды — моя любимая фича в Java, а обработка исключений в них, наоборот, вызывает больше всего негативных эмоций. Вам обязательно нужно поймать исключение внутри лямбда-выражения.

Как именно протекает его деятельность? Олег: Вы упомянули исполнительный комитет JCP. У вас есть своё здание для встреч, своего рода «Белый дом», как у настоящего правительства?

Мы проводим регулярные встречи, но чаще всего они проходят в форме телеконференций. Саймон: (смеется) Думаю, мы больше похожи на комитет по стандартам. У нас нет постоянного офиса, все встречи организуются различными компаниями на добровольческой основе. Три или четыре раза в год мы собираемся в одном помещении и в течение дня или двух обсуждаем вещи вроде JSR. Эта система нам отлично подходит, и на самих мероприятиях обычно очень дружелюбная атмосфера. В Великобритании их проводила IBM, в Болгарии — SAP, а в ближайшем будущем будет встреча в Японии, её организует Fujitsu. Конечно, у нас бывают и споры, но в целом в комитете отличные люди.

Ведь Java — очень сложная система, можно нечаянно всё сломать. Олег: А вам, как члену экспертной группы, не страшно добавлять новые фичи?

В свое время Sun сделали исходный код открытым и создали OpenJDK, сейчас он всё в большей степени направляет развитие Java в целом. Саймон: За последние два-три года функционирование экспертной группы существенно изменилось. Иногда эти предложения поступают извне — от Azul, Red Hat, IBM и даже Google. Конкретные фичи предлагаются через JEP (JDK Enhancement Proposal). Oracle принадлежит функция своего рода попечителей, стюардов языка. Но контроль в конечном итоге всё равно принадлежит Oracle: они выполняют большую часть работы и определяют направление развития. Сейчас новая версия выходит каждые полгода, и я замечаю, что разработчики не боятся отложить фичу до следующего релиза, если она ещё не доведена до ума. Благодаря им внесение новых фич происходит упорядоченно, они стараются не торопиться без нужды. Прекрасный пример его — JDK 12, который выходит в следующем месяце. Мне очень нравится такой ответственный подход. Изначально в него хотели включить string literals, но потом решили, что их нужно ещё доработать.

Мы с Саймоном гуляем по Java-конференции JBreak год назад

Олег: А вы и ваша компания уже перешли на Java 11 или 12?

Из моих разговоров с разработчиками по всему миру у меня складывается впечатление, что люди постепенно переходят на JDK 11, потому что это релиз с долгосрочной поддержкой. Саймон: В своих проектах я часто использую Java 11, но это обычно код не для продакшна, он, скорее, экспериментальный. За коммерческое использование теперь нужно платить. Конечно, надо иметь в виду, что эта поддержка предоставляется сейчас на других условиях, чем раньше. Это Azul, AdoptOpenJDK, Amazon Coretto. Есть компании, которые следуют тому же графику релизов, что и Oracle. Как правило, люди не готовы переходить на новую версию каждые шесть месяцев, в особенности в продакшне. Они рассчитывают на то, что JDK 11 будет иметь долгосрочную поддержку, а следующим долгосрочным релизом будет JDK 17. По крайней мере, сейчас это так. Возможно, это смогут делать стартапы, но большинству коммерческих пользователей нужна стабильность.

Поскольку тестирование всё равно необходимо, они предлагают другие подходы, о которых они рассказали на последней конференции FOSDEM, разные сумасшедшие штуки вроде машинного обучения. Олег: Кстати говоря, насколько мне известно, AdoptOpenJDK не используют тесты TCK. А у вас много усилий уходит на поддержание своего форка OpenJDK? В числе этих подходов были радикальные вещи вроде машинного обучения.

Правда, нужно и время, и инфраструктура. Саймон: На самом деле, это не так уж и сложно. Собрать свой собственный JDK достаточно легко, скрипты для сборки работают хорошо. В AdoptOpenJDK ее предоставляют различные спонсоры, в том числе Azul. Далее вам необходимо определиться, нужно ли вам соответствовать стандарту Java SE. В этом плане ситуация существенно изменилась по сравнению с тем, что было, когда OpenJDK только появился на свет. Получить TCK от Oracle можно бесплатно, если вы просто хотите сделать свою сборку OpenJDK. Для этого как раз и нужен TCK. Думаю, это связано с тем, что они параллельно собирают проект OpenJ9 для IBM. Я точно не знаю, почему именно у AdoptOpenJDK нет лицензии TCK. Это моё предположение, но если вы хотите узнать наверняка, вам придётся спросить у самих разработчиков AdoptOpenJDK. А проект может получить TCK только в том случае, если он в основном базируется на OpenJDK. Поскольку код, на котором они основывались, является эталонной реализацией, скорее всего он этому стандарту отвечает, но точной уверенности без TCK у нас нет. Так или иначе, у них сейчас нет возможности удостовериться, что их проект соответствует стандарту Java SE. То есть это высокоуровневое тестирование, а не просто проверка соответствия стандарту. Но у AdoptOpenJDK много других тестов, которые в основном проверяют, как на JDK запускаются приложения.

Не могли бы вы рассказать про него? Олег: У Azul есть свой дистрибутив OpenJDK, Zulu. В чём разница между ним и всеми остальными? Он опенсорсный?

По большому счёту, здесь такой же подход, как и у Red Hat. Саймон: У Zulu есть две версии — Community Edition и Enterprise Edition. Она распространяется под лицензией GPLv2 with Classpath Exception, т.е. Community Edition — открытая версия, её можно скачать с нашего сайта. Но у этой версии нет коммерческой поддержки. той же, что и OpenJDK, поэтому ей можно пользоваться так, как вам заблагорассудится. Между этими версиями есть различие в том, как происходят обновления. Zulu Enterprise Edition ориентирована на крупные организации, которым нужна платная поддержка продукта. Когда Oracle выпускает обновление для очередной версии JDK, скажем, 12 или 13, мы очень быстро делаем его доступным для 8, 7 и даже 6 версии Zulu Enterprise. Для Enterprise Edition мы делаем бэкпорты самостоятельно. Если фиксы уже есть в этом коде, то они будут и в Community Edition, если же бэкпортов никто другой не сделал, то и в Community Edition их не будет. В Community Edition мы просто берём исходный код OpenJDK и собираем его. По-моему, это здравый подход.

Например, сейчас есть несколько низкопаузных сборщиков мусора, а в Oracle Labs был создан JIT-компилятор Graal, аналогичный Falcon от Azul. Олег: В последнее время у целого ряда компаний появились продукты, близкие к тому, что делает Azul. Вы можете рассказать нам, что именно представляют из себя C4 и Falcon, и в чём их отличие от аналогичных продуктов других компаний?

C4 — сборщик мусора, который не делает остановок stop-the-world, в отличие от традиционных сборщиков мусора, скажем, CMS, G1 и так далее. Саймон: Давайте начнём со сборщиков мусора. Сейчас он работает очень стабильно, и мы его много где используем. Над C4 мы работали больше десяти лет. Один из таких сборщиков мусора — ZGC от Oracle, который недавно стал открытым и вошёл в состав OpenJDK. Но за это время действительно появилось несколько аналогичных сборщиков мусора от наших конкурентов. Например, для доступа к объектам используется барьеры чтения, а не барьеры записи. В ZGC много решений, схожих с теми, которые использует C4. Но проблема в том, что это опенсорсный проект, и Oracle не занимается его активной разработкой. Он работает почти так же хорошо, как и наш. До того, как он стал опенсорсным, над ним работало всего два программиста из Швеции. Насколько мне известно, они не планируют включать его в свои коммерческие продукты, он скорее носит экспериментальный характер. Я общался с некоторыми людьми, которые пользовались ZGC, и, по их словам, он даёт неплохие результаты, но стабильность оставляет желать лучшего — по крайней мере, они не стали бы использовать его в коммерческом приложении. Так что здесь необходимо быть осторожным, поскольку не вполне понятно, насколько этот проект стабилен.

Он ориентирован на приложения с большими кучами, минимум 20 гигабайт, в то время как у Zing минимальный размер кучи — один гигабайт. Shenandoah — это сборщик мусора от Red Hat. Над ним работают Christine Flood и Алексей Шипилёв, оба прекрасно разбираются в своём деле. Shenandoah по-прежнему находится в разработке, и она продолжается уже продолжительное время. Имеющиеся на сегодняшний день результаты свидетельствуют о том, что более успешным был бы традиционный подход, т.е. Насколько я понимаю, Shenandoah сейчас использует кучу с одним поколением. Скорее всего, здесь ещё есть над чем поработать. несколько поколений. Из наших клиентов пока никто не перешёл на Shenandoah или ZGC. Сейчас Shenandoah входит в состав OpenJDK 12 как экспериментальная фича, и это прекрасно, поскольку это даёт пользователям выбор. Возможно, кто-то захочет это сделать в будущем.

Но C2 уже больше 20 лет, и он написан довольно сложно, его трудно будет модифицировать. Что касается JIT-компиляторов, мы хотели улучшить код, который они генерируют, и поначалу ориентировались на компилятор C2. Мы взяли их исходный код и интегрировали его в JVM. Мы также рассматривали LLVM, это опенсорсный проект, который занимается компиляторами. Поскольку мы добропорядочные участники опенсорсного сообщества, мы добавили эти изменения к проекту LLVM. LLVM в основном выполняет статическую AOT-компиляцию, у нас эта технология использовалась для JIT-компиляции. Кроме того, над LLVM сейчас работают люди из Intel, Sony, Microsoft, что, безусловно, сильно нам помогает. У нас получилась очень элегантная модульная структура, благодаря которой легко добавлять новые фичи, так что можно вносить новые интринсики, новые модули и т.п. Каждый раз, когда мы обновляем наш исходный код, мы получаем улучшения в производительности, сделанные другими людьми.

Это экспериментальный JIT-компилятор, написанный на Java, который задумывался как альтернатива для C2. Перейдём теперь к Graal. Компилятор Graal — часть более крупного замысла, GraalVM. В большинстве случаев Falcon даёт значительно лучшие результаты, чем Graal. Там будет не только Java, но и другие языки. В ней пытаются найти альтернативный подход к тому, как запускаются приложения. Думаю, никто не хочет, чтобы у нас остался только один способ сборки мусора или JIT-компиляции. В целом, меня радует, что в этом направлении ведётся много исследований и существует много альтернативных проектов. У людей есть выбор, и это правильно.

Спасибо! Олег: Честно признаться, я не ожидал такого всеобъемлющего ответа. Четверть программы JPoint посвящена реактивным технологиям. Сейчас делается много докладов про микросервисы, микро-инстансы в облачных средах, даже легковесные облачные функции. Но для небольшого инстанса с маленькой кучей не нужен мощный сборщик мусора. Все больше людей советует создавать не крупные сервисы, а небольшие инстансы. Какое будущее у умных сборщиков мусора и умных JIT-компиляторов? Можно даже использовать сверхбыстрые сборщики мусора вроде того, который используется в Golang. Сохраняют ли они свою актуальность?

Микросервисы — интересный термин, и, на мой взгляд, не вполне точный. Саймон: Безусловно. Основной принцип микросервисов — специализация, для достижения которой большое монолитное приложение разбивается на ряд отдельных сервисов. Было бы правильнее называть их просто сервисами. Но здесь важно понять, что микросервис не обязательно должен быть маленьким. Один такой сервис может выполнять транзакции по кредитным картам, другой обеспечивает работу корзины для онлайн-магазина, третий занимается хранением данных. Такой кластер можно считать микросервисом — у него только одна задача, с которой он отлично справляется. В качестве примера можно привести кластеры Cassandra. Несмотря на то, что они выполняют только одну задачу, они обрабатывают большие объемы данных. Но при этом у них довольно внушительные размеры и большая куча.

В итоге возникает больше проблем, чем при сохранении высокоуровневой архитектуры. Кроме того, я могу сказать по своему многолетнему опыту работы со многими проектами, что при разбиении приложения на части нужно быть осторожным. Когда с приложением возникает проблема, в особенности связанная с производительностью, им оказывается тяжело определить, какой именно сервис её вызывает. Я как раз обсуждаю сейчас эту тему с моими клиентами, которые перешли на архитектуру микросервисов. Они не могут просто запустить инструмент отслеживания производительности на своём приложении, им приходится отслеживать множество различных мест и просматривать сообщения, которыми обмениваются сервисы. Им теперь нужен анализ множества сервисов, запущенных во множестве различных мест. Разобраться во взаимодействиях между микросервисами значительно сложнее, чем во взаимодействиях между частями одного приложения.

В JDK 11 был добавлен сборщик мусора Epsilon, который не собирает мусор. Действительно, сейчас есть тренд в сторону небольших микросервисов, которые запускаются очень быстро, требуют минимум ресурсов, небольшую кучу, и им хватает сборщика мусора Golang. Безусловно, есть ситуации, в которых этот подход может работать, но значительной части реальных приложений всё равно будет нужна куча и сборка мусора. Ход мысли здесь такой: если у нас бессерверные вычисления, все микросервисы запущены на облаке, и у них нет состояния, то сборка мусора и не нужна — разве это не прогресс? В общем, микросервисы — это прекрасно, но с ними важно не зайти слишком далеко. А значит, им будут нужны различные подходы к высокопроизводительной сборке мусора.

Примерно две недели назад GlassFish стал частью Eclipse. Олег: А как насчёт крупных серверов приложений, которые работают в качестве платформ для сервисов? Думаете ли вы, что это правильный путь развития?

Микросервисы сейчас определённо в моде, но я не знаю, насколько они будут жизнеспособны в долгосрочной перспективе. Саймон: Мне кажется, что для разных приложений хороши разные подходы. Вопрос в том, сможем ли мы найти максимально простое решение для них. Тут есть много трудностей, которые, правда, преодолимы. Нам нужны решения именно такого характера. Kubernetes — отличное дополнение к микросервисам, он позволяет управлять ими и упрощает работу.

Docker, Kubernetes и т.п. Олег: Eclipse и Jakarta EE утверждают, что их главная фича — интеграция в облачной среде, т.е. Жизнеспособна ли она там? Какое место занимает Java в облачных технологиях? Можно ли запустить Falcon на Arm64?

Но здесь опять-таки нам помогает тот факт, что в LLVM участвуют многие крупные компании, в том числе ARM. Саймон: Безусловно, если вы хотите запустить Falcon на другой архитектуре, вам придётся дополнительно поработать. Благодаря этому преимуществу мы можем работать с различными облачными архитектурами, и мне не видится здесь никаких затруднений для нас. Они знают свою архитектуру, и поэтому могут добиться отличной совместимости компилятора с ней.

Как вам кажется, это к лучшему или нет? Олег: Кстати говоря, Java Enterprise и JavaFX больше не входят в дистрибутив OpenJDK. И, в целом, какой ваш взгляд на будущее Java EE и JavaFX?

Если мне не изменяет память, JavaFX появилась аж в 2004 году. Саймон: C JavaFX ситуация проще, поэтому давайте начнём с неё. Я написал довольно много кода на JavaFX, и она мне очень нравится. Это была интересная попытка предоставить более совершенное средство разработки UI. Тем не менее, JavaFX так и не стала частью стандарта Java SE, как этого многие хотели. С ней значительно проще, чем со Swing и AWT, благодаря наличию поддержки style sheets, различных способов работы с layouts и так далее. Но большой проблемы в том, что они не включают его в JDK, на мой взгляд нету. Oracle решили, что больше не будут вкладываться в этот проект, и открыли исходники для него. Azul может предоставлять поддержку JavaFX как часть поддержки Zulu. При желании вы вполне можете пользоваться JavaFX, как это делает, скажем, Gluon. В общем, здесь всё просто.

В их числе JAX-B и CORBA, её из известных мне людей не использует сейчас никто, так что это не страшно. Что касается Java EE, то, как мы знаем, в JDK 11 был удалён модуль java.se.ee — это агрегатор, включающий в себя шесть других модулей. Но, опять-таки, благодаря наличию модульной системы сейчас относительно несложно получить опенсорсную версию необходимого вам модуля, если он был удалён из JDK. А вот удаление JAX-WS не всеми было хорошо воспринято. ч. Поддержка для этого есть в т. Поэтому я считаю, что со стороны Oracle было правильным решением почистить Java. на Maven Central. Java уже 24 года, и нам нужно активнее удалять старые фичи, которыми люди уже не пользуются. Я уже говорил, что в прошлом, наверное, следовало более активно избавляться от устаревших модулей. Короче говоря, я считаю, что этот подход правильный. Это также упростит жизнь разработчикам OpenJDK, поскольку уменьшится количество кода, которое нужно поддерживать.

Было ли тяжело её получить? Олег: Последний вопрос, будете ли вы JPoint, и если да, то как дела с российской визой?

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

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

Я подавал заявление через специальную компанию, так что мне нужно было только заполнить анкету, дать им фотографию и отпечатки пальцев. На самом деле, всё было не так уж и страшно. Это существенно облегчило процесс.

Олег: А чему будет посвящён ваш доклад на конференции?

Речь пойдёт о версиях с 9 по 12, а также о замыслах на будущее. Саймон: Я буду рассказывать о том, что Java с новым графиком релизов стала развиваться быстрее, но при этом более мелкими шагами. Loom позволит сделать треды более легковесными и позволит привязывать множество файберов к одному треду операционной системы. В числе этих замыслов — проект Valhalla с его value types и reified generics, а также проект Loom с его fibers. Также я расскажу о проекте Amber, который позволит почистить синтаксис Java и сделать его менее многословным. Это улучит производительность приложений. В общем, это будет краткий обзор существующих и планируемых фич.

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

Да, целых два. Саймон говорит о своих свежих докладах на JPoint 2019: «JDK 12: Pitfalls for the unwary» и «Local variable type inference: Friend or foe?». JPoint 2019 пройдёт 5-6 апреля, с первого апреля билеты подорожают. Также в программе заявлены доклады от команды GraalVM (Thomas Wuerthinger и Олег Шелаев), Liberica JDK (Дмитрий Чуйко), Excelsior JET (Никита Липский), и т.п.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] История транзистора, часть 2: из горнила войны

Другие статьи цикла: История реле История электронных компьютеров История транзистора Горнило войны подготовило почву для появления транзистора. С 1939 по 1945 года технические знания из области полупроводников невероятно сильно разрослись. И тому была одна простая причина: радар. Самая важная технология ...

Что можно сделать через разъем OBD в автомобиле

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