Java: fill the gaps

​Вопрос 1. Что выведется на консоль?

Интерфейсы, часть 1: поля и методы Интерфейс — базовый механизм джавы для поддержки ООП, а также главный герой этой недели🦸🏼‍♂️ 🔸 Какие методы можно добавить в интерфейс в разных версиях java? Java 7 — только нестатические public методы:

interface Интерфейс {
  public void метод();
}

Классы реализуют эти методы под угрозой ошибки компиляции. Java 8 — плюс 2 возможности: ▪️Методы по умолчанию с заданной реализацией:

default void метод() {…};

Конкретный класс переопределяет его при необходимости. Дефолтные методы уместны в трёх случаях, об этом будет статья в среду. ▪️ Статические методы с реализацией:

static void метод() {…};

Статические методы не наследуются и не переопределяются. Вызвать такой метод можно только через имя интерфейса:

Интерфейс.метод()

Зачем он нужен? В интерфейсе определяется необходимый минимум методов. Например, в Collection это методы add(), remove() и пара других. Чем меньше методов, тем больше свободы действий у конкретных классов. Эти базовые методы комбинируются между собой в другие полезные методы: ▪️Поиск элемента, ▪️Поиск минимального элемента ▪️Скопировать коллекцию Каждый из этих методов — всего лишь комбинация базовых, которая не зависит от конкретного класса. Чтобы не копировать код в каждый класс, удобно вынести его в статический метод в интерфейсе:

static E copy() {…};

До java 8 статические методы часто объединяли в утилитный класс с похожим именем. Например, методы binarySearch, copy, min реализованы в классе Collections. Java 9 — добавились private и private static методы с реализацией:

private void m() {…};
private static void m() {…};

Эти методы недоступны для классов, реализующих интерфейс. Зачем они нужны? Код внутри дефолтных и статических методов может дублироваться. Чтобы улучшить читаемость, можно вынести общие части в приватный метод. 🔸 С методами разобрались, а какие поля можно добавлять в интерфейс? Только константы с модификаторами public static. Из-за того, что других вариантов нет, в Intellij IDEA public и static подсвечиваются как избыточные и вместо

public static int NUM = 1;

допустима запись:

int NUM = 1;

Такие поля компилируются в статические! 🔸 Правильный ответ на вопрос перед постом Ошибку компиляции в последней версии java вызовут:

default int get();
private int get();
public static int get();

У приватных, статических и default методов в интерфейсах должна быть реализация.

Security basics, часть 4: JWT Статей про JWT много, но все они делают упор на авторизацию. Но JWT используется по-разному, поэтому начну с общей схемы, а потом перейду на auth. Возьмём как пример интернет-магазин. Пользователь что-то смотрит, добавляет товары в корзину, отмечает какие-то опции. ❓ Вопрос — где хранить корзину с товарами? 🔸 На сервере Когда клиент начинает работу с приложением, на сервере создаётся запись типа

sessionID - { /*info*/ }

Там хранится информация для текущего сеанса. Когда пользователь вводит логин-пароль, то получает обратно sessionID. SessionID сохраняется в cookies и автоматически добавляется в каждый запрос. Так сервер понимает, какой пользователь прислал запрос, и с какой информацией работать. 🔸 На клиенте Если на сервере не хранится ничего временного, то в каждом запросе клиент отправляет все нужные данные. Браузер отправил логин-пароль — получил обратно имя пользователя и количество накопленных баллов. Сохранил у себя. Пользователю интересны варианты доставки? В запросе отправляется город, накопленные баллы и другая информация для расчёта. И тут вопрос — что мешает клиенту передать ложную информацию? Например, что у него 9999999 бонусных баллов. Тут мы подходим к JWT, он гарантирует корректность присланных ранее данных. Как это работает: 1️⃣ Сервер шлёт какую-то информацию и подписывает её:

"bonus":10
"bonus sign":"Dfhdy76" 

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

"city":"moscow"
"bonus":10 
"bonus sign":"Dfhdy76" 

3️⃣ Сервер проверяет корректность своим публичным ключом. Если клиент пришлёт "bonus" : 99999, то сервер сразу распознает обман. JWT токен состоит из 3х частей: ▪️ Заголовок с алгоритмом подписи:

{"alg":"HS256", "typ":"JWT"}

▪️ Что-то полезное:

{"bonus":10, "status":"vip"}

▪️ Подпись По сути это два JSON и строка. Чтобы передавать это как цельный объект, каждая часть кодируется Base64. Части соединяются между собой через точку в одну строку:

eyJh.TYDkwI.SflKxwRJSM

И хотя механизм универсальный, чаще всего он используется для авторизации и помогает серверу понять, кто выполняет запрос: 🔹 Пользователь вводит логин пароль 🔹 Сервер отвечает JWT токеном, внутри которого что-то вроде

"userId":34563847638

🔹 Токен каждый раз передаётся в хэдере HTTP запроса 🔹 Сервер валидирует подпись Важные дополнения: JWT ничего не шифрует, только заверяет подлинность данных. Поэтому в JWT токенах не следует передавать пароли или что-то секретное. Важно, чтобы JWT токены хранились и передавались безопасно. Ведь если токен с авторизацией перехватит злоумышленник, то он сможет выдать себя за пользователя. Что делать: использовать HTTPS и самые новые версии браузеров с безопасным хранением cookies. В принципе это всё, что нужно для базового понимания JWT. Больше деталей: ▫️ JWT Security Best Practices ▫️ Спецификация JWT

На прошлой неделе мы обсуждали, как защитить данные. На этой неделе я запланировала другую тему — авторизация и аутентификации. 🔸 Аутентификация — проверить, что пользователь тот, за кого себя выдаёт 🔸 Авторизация — есть ли у пользователя права на конкретное действие С этим редко бывают сложности. Гораздо интереснее темы, которые идут рядом: JWT, oAuth, SSO и как это всё работает со Spring Security. Тут легко увлечься, но нельзя сказать, что такие задачи приходят каждый день. Так что сегодня расскажу о JWT, а остальное — как-нибудь потом🙃

Security basics, часть 3: HTTPS Вернёмся к ситуации, которую затронули пару дней назад. Пользователь открывает сайт и хочет ввести пароль, данные карты или другую важную информацию. Симметричное шифрование здесь не подходит — непонятно как безопасно доставить ключ пользователю. Все механизмы безопасности складываются из простых кирпичиков, и HTTPS не исключение: 🔸 Браузер присылает свой публичный ключ 🔸 Сервер присылает свой публичный ключ 🔸 Сервер и браузер вычисляют Общий ключ (shared secret) на основе своих приватных ключей и полученных публичных Так через ассиметричное шифрование легко переходим к симметричному. Последний пункт выглядит как магия, но это всё математика. Спасибо криптографии за чудесные алгоритмы ❤️ Процесс выше называется TLS Handshake. Скорее всего вы часто видели аббревиатуру SSL. Этот протокол появился в 90е и давно устарел, а ему на смену пришёл TLS. Но многие по старинке говорят SSL, иногда ещё пишется SSL/TLS. Давайте опишем тот же процесс, но чуть подробней: 1️⃣ Браузер шлёт: ▫️ Алгоритмы, которые знает браузер ▫️ Свои публичные ключи и соответствующие алгоритмы ▫️ Случайное число №1 2️⃣ Сервер Выбирает из списка алгоритмов подходящий для дальнейшего общения и запоминает публичный ключ браузера для выбранного алгоритма. Обратно шлёт ▫️ Названия выбранных алгоритмов ▫️ Свой публичный ключ ▫️ Сертификат ▫️ Случайное число №2 3️⃣ Обе стороны вычисляют Общий ключ и продолжают общаться Больше технических подробностей читайте в статье TLS (SSL) handshakes explained. Разберём несколько вопросов "Зачем": ❓ Зачем браузер и сервер переходят на симметричное шифрование? Почему бы не продолжить шифровать сообщения публичными ключами? Общий ключ короче и вычисления гораздо проще. Поэтому симметричные алгоритмы выполняются в тысячи раз быстрее ассиметричных. ❓ Зачем в сообщениях случайные числа? Чтобы избежать Replay attack. Злоумышленник может прослушать сообщение и отправить от своего имени. Или отправить сообщение несколько раз, чтобы запутать получателя. Получатель запоминает число и не принимает сообщения с тем же числом. ❓ Зачем нужен сертификат? Доказать, что сайт не фишинговый. В сертификате прописан: ▫️ Домен ▫️ Публичный ключ ▫️ Срок действия сертификата ▫️ Цифровая подпись Сертификат подписывает: 🔹 Сам сервер своим приватным ключом. Браузер распознаёт самоподписанные сертификаты и выдаёт предупреждение. Но для разработки и тестирования такой вариант подойдёт 🔹 Специальная организация — Certificate Authority. Список СА хранится в операционной системе и в некоторых браузерах Следить за сертификатами — задача девопса. Если срок действия сертификата истёк, то пользователи увидят надпись на весь экран, что сайту нельзя доверять. ❓ Зачем мне эта информация? Чем выше ваша позиция, тем шире круг задач и проблем, которые нужно решать. И здесь очень важен общий кругозор. Плюс, чем больше вы знаете, как устроен мир, тем больше фундамент для ваших собственных решений🙂

Security basics, часть 2: цифровая подпись и немножко терминов Давайте чётко обозначим разницу между терминами: 🔸 Хэширование Цель — получить краткое представление объекта.

Objects.hash("пирожок") = 564453454

Результат не зависит от внешних параметров. Объект обратно восстановить нельзя. Самые популярный алгоритм — SHA, иногда используется MD5. 🔸 Кодирование Цель — преобразовать сообщение для передачи. Используется при ограничениях на формат сообщений. Пример: нужно передать JSON туда, где ожидается обычный текст. Кодировка Base64 переводит любой битовый массив в простые символы — цифры, латинские буквы, +, / и =. Уйдут скобки, кавычки и всё, что может смутить канал передачи или библиотеку получателя.

Base64.encode("{"/пирожок"/}") = "TWFuIGlzIGRpc3Rp=

" После получения закодированное сообщение приводится к исходному виду:

Base64.decode("TWFuIGlzIGRpc3Rp=") = "{"/пирожок"/}

" 🔸 Шифрование Цель — защитить сообщение от посторонних. Зашифровать и прочитать сообщение могут только обладатели связанных ключей Хэширование, кодирование и шифрование — это кирпичики, из которых собираются остальные механизмы безопасности. 🔹Например, электронная подпись Это файлик с расширением .sig, который прилагается к сообщению и доказывает его подлинность. Само сообщение передаётся в открытом виде и никак не скрывается. ❓ Как это работает? Подпись может быть на основе любого алгоритма шифрования: Симметричный алгоритм (редко используется): ▫️ Отправитель вычисляет хэш сообщения и шифрует его ключом ▫️ Получатель выполняет те же действия со своим ключом и сравнивает значение с присланной подписью ▫️ Если сообщение изменилось (поменялся хэш) или использовался не тот ключ, то значения не совпадут. Нет доверия такому документу🙂 Ассиметричный алгоритм: ▪️ Отправитель формирует подпись из хэша сообщения и приватного ключа ▪️ Получатель для проверки вызывает функцию, которая соотносит подпись, хэш сообщения и публичный ключ Таким образом электронная подпись — это сочетание хэширования и шифрования. В JDK всё это находится в пакете java.security.

Security basics, часть 1: симметричное и ассиметричное шифрование Начнём с простой задачи: передать секретное сообщение по общедоступной сети. Злоумышленник может прослушать канал связи, перехватить сообщение и даже поменять его. Такой тип атаки называется man in the middle🕵️ Что делать? Самое простое — преобразовать сообщение, чтобы при перехвате злоумышленник ничего не понял. Например, сдвинуть каждую букву на 1:

Пирожок → Рйспзпл

Получатель выполнит обратную операцию и расшифрует сообщение. Но для стандартных алгоритмов то же самое легко сделает и злоумышленник. Поэтому в преобразования вводится дополнительный параметр и формула становится сложнее. Например: символ → символ + k Параметр (или ключ) вносит больше неопределённости в результат. Ключ может быть одним числом или состоять из нескольких чисел. Злоумышленнику нужно гораздо больше времени, чтобы взломать такой шифр. 🔸 Если для расшифровки используется тот же ключ, что и для шифрования, алгоритм называется симметричным. Наиболее популярен алгоритм AES и его производные. Они, разумеется, более сложные, чем пример выше — сообщения делятся на блоки, блоки перемешиваются, внутри каждого блока выполняются десятки операций, и всё это проходит в несколько раундов. На практике такой тип шифрования используется редко. Представьте, вы открыли сайт в браузере и хотите залогиниться. Чтобы безопасно передать пароль, вам с сервером нужен общий ключ. Но как получить его — непонятно. 🔸 Поэтому чаще применяется ассиметричное шифрование. Создаётся пара ключей: один называется публичным, а другой — приватным. 🗝 Публичный ключ свободно распространяется и позволяет шифровать сообщения 🗝 Приватный ключ остаётся у получателя. И только он расшифрует полученное сообщение Самый популярный ассимметричный алгоритм — RSA. Он основан на простых числах, вычислении степени и остатке от деления. Формулы несложные, а шифр получается вполне стойкий. В последнее время в тренды выходит EdDSA. Он популярен тем, что активно используется в биткоине. Поддержка этого алгоритма появилась только в java 15. Вообще алгоритмы шифрования используются не только для шифрования, но и входят в состав остальных инструментов безопасности. Но об этом позже🙂

Привет! Тема ближайших двух недель — безопасность. Обычно детали скрыты за библиотеками и фреймворками, но важно понимать принцип работы, чтобы не сделать глупых ошибок. У новичков часто не складывается общая картина, поэтому пойдём шаг за шагом и закроем возможные пробелы. 🔸 Часть 1. Симметричное и ассиметричное шифрование 🔸 Часть 2: Цифровые подписи 🔸 Часть 3: HTTPS А на следующей неделе подробнее поговорим про авторизацию и аутентификацию.

Зачем спрашивать про хэшмэп Меня раньше раздражали многие вопросы с собеседований: ▫️ Перечислить методы класса Object ▫️ Рассказать строение HashMap и списков ▫️ Расшифровать SOLID ▫️ Вставить элемент в сбалансированное дерево Задают везде по сто раз, они мало связаны с ежедневной работой и вообще неинтересные. С годами отношение поменялось. Представьте, вам нужно нанять человека в команду для несложных (на ваш взгляд) задач. Вы и парочка сеньоров будете направлять его и подстраховывать. Что ожидается от джуниора и мидла: ▫️ Hard skills: уметь писать на java, знать основные структуры данных, паттерны и фреймворки ▫️ Soft skills: быть приятным в общении, чётко формулировать мысли и возможные проблемы Хард скиллс более-менее проверяется тестами и конкретными вопросами. Но никто не назовёт себя раздражительным, поэтому софт скиллс проверяются косвенно. Интервьюер: расскажите устройство HashMap 👦🏽 Кандидат 1: закатывает глаза и вздыхает. Ну там хэши, бакеты, я это уже сто раз рассказывал на другом собесе, давайте дальше 🧔Кандидат 2: чётко и понятно отвечает на вопрос 👨🏻 Кандидат 3: чётко и понятно отвечает на вопрос, упоминает изменения в java 8, готов обсудить ConcurrentHashMap и его эволюцию Понятно, что Кандидат 2 — отличный парень, Кандидат 3 — вообще лапочка. И по хард скиллам хорошо, и работать с ним будет приятно. ❓ Означают ли стандартные вопросы, что проект скучный? Мне кажется, корреляция между собеседованием и дальнейшей работой довольно низкая. Бывало, что собеседование долгое и тщательное, а проект так себе. И наоборот — вопросы простейшие, а проект — конфетка. В любом случае нужно спрашивать, что происходит в проекте, какие там технологии, задачи и перспективы. ❓ Что делать, если вопросы на интервью стандартные, но хочется показать себя во всей красе? Хорошо отвечайте на эти стандартные вопросы. Если на интервью видно ваш крепкий фундамент, значит вы без труда подстроитесь под любой стек и любые специфичные задачи. Плюс всегда есть момент, чтобы ввернуть ваши интересы или достижения. Как минимум указать в резюме и кратко описать в первой части интервью. ❓ Что проверяют у сеньора, когда задают вопрос про HashMap? Сеньор не только пишет классный код, но и помогает младшим товарищам. Джуниорам и мидлам придётся часто повторять одно и то же, понятно и доброжелательно. Так что вопрос про хэшмэп вполне подойдёт. Хард скиллы проверяются, конечно, другими вопросами.

Intellij IDEA: создать и переместить строку Как создают строчку обычные люди: долго переводят курсор в конец строки и жмут Enter. В IDEA достаточно нажать

Shift + Enter

И вы сразу перейдёте на новую строчку Быстро перемещать строки:

Shift + Alt + (стрелка вверх/вниз)

Если выделить несколько строк, то группа будет двигаться целиком. Очень простые и приятные фичи🙂

Как написать hashcode лучше, чем IDE Метод hashcode используется, когда класс работает в качестве ключа в hash-based структурах данных. Следить за тем, как используется класс, не всегда удобно, поэтому есть правило — "Переопределяешь equals — переопредели hashcode". Метод должен соблюдать контракт: ⭐️ Если объект не меняется, хэшкод остаётся постоянным ⭐️ У одинаковых объектов одинаковый хэшкод ⭐️ Если хэшкод одинаковый, то объекты не обязательно равны Писать equals и hashcode вручную долго, поэтому часто используется автогенерация в IDE или Lombok аннотация @EqualsAndHashCode. Они создают что-то вроде

public int hashcode() {
  return Objects.hash(id, param1, param2);
}

Что не так? Контракт соблюдается, но суть хэшкода пропадает. Хэшкод — это быстрая проверка без лишних вычислений. В коде выше результат вычисляется каждый раз на основе множества полей. А по количеству операций Objects.hashcode догоняет equals. Как считать хэш быстрее: 1️⃣ Использовать одно поле

public int hashcode() {
   return id;
}

2️⃣ Сохранять результат в отдельном поле Подойдёт если у объекта нет id, и основные поля не меняются. Так сделано в классе String:

private int hash;

public int hashCode() {
  int h = hash;
  if (h==0 && !hashIsZero){
     hash = …;
  }
  return h;
}

Эффект от оптимизации будет заметен, если класс активно участвует в hash-based структурах. В остальных случаях можно оставить автогенерацию.

Первым делом хочу поблагодарить всех, кто ответил на анкету и особенно на последний вопрос. Было много приятных пожеланий и интересных идей! Спасибо🥰 Ну а теперь к делу ⬇️

Привет! Каждый автор пишет о том, что ему интересно, и что больше откликается у аудитории. Я в основном пишу про java core, но хочется писать и на другие темы. Поэтому хочу узнать про вас чуть больше. Ответьте, пожалуйста, на 2 вопроса выше ⬆️ А если уделите ещё 5 минут и ответите на эту анкету, то сильно мне поможете и напрямую повлияете на будущий контент.

Гороскоп на 2022 Хороший год начинается с астрологического прогноза. Если ваши спринты по две недели (половина лунного цикла), а сервисы развёртываются в облаках, то этот небесный прогноз для вас. ♈️ Овен (21 марта — 20 апреля) В этом году возможен большой шаг в карьере, но он не будет простым. Откажитесь от лишней эмоциональности и просто идите в выбранном направлении. Посмотрите книгу Программист-прагматик, там для вас есть дельный совет. ♉️ Телец (21 апреля — 20 мая) Год будет богат на свежие идеи и начинания. Начните то, что давно откладывали, расширяйте кругозор и пробуйте новое. Обязательно делайте бэкапы и резервные копии. Поездите по России, вам понравится. Петербург, Краснодар, Кисловодск, Байкал, Алтай, Кавказ🧡 Во второй половине года порадуйте себя новой техникой. ♊️ Близнецы (21 мая — 21 июня) В этом году сделайте упор на soft skills. Навыки переговоров, управления и тайм-менеджмента ускорят ваше продвижение вперёд. Сентябрь станет самым прибыльным месяцем в году. Первая половина года подкинет отличную карьерную возможность, не упустите её. ♋️ Рак (22 июня — 22 июля) Лучшее время для решительных шагов — начало весны. Много возможностей принесёт нетворкинг — поддерживайте тёплые отношения с коллегами, участвуйте в конференциях, митапах и корпоративных мероприятиях. Если ещё не смотрели в сторону Kotlin, самое время это сделать. ♌️ Лев (23 июля — 23 августа) Год будет спокойным и приятным. В прошлом году вы много работали, в 2022 выделяйте больше времени на отдых. Качество жизни и работы только улучшится. Отличное время для серьёзного обучения — начните какую-нибудь большую книгу или впишитесь в долгие курсы. Ложитесь спать пораньше, на выходных не заглядывайте в рабочие чаты. ♍️ Дева (24 августа — 22 сентября) В этом году вы будете на переднем фронте. Вас ждут горячие фиксы и спасение команды перед дедлайном. Будет сложно, но Юпитер вам поможет. Помните об отдыхе и набирайтесь сил в спокойное время. Зимой возможны серьёзные ошибки в коде или конфигурации, уделите больше времени самопроверке и написанию тестов. ♎️ Весы (23 сентября — 23 октября) Водный тигр симпатизирует вам, поэтому все инициативы будут удачны, особенно весной и летом. Будьте активны на ретро, предлагайте новые фичи и подходы, возьмите под наставничество стажёров. Никогда ничего не бойтесь, живите здесь и сейчас ♏️ Скорпион (24 октября — 22 ноября) В этом году Скорпионам достанутся важные и сложные задачи. Карьерный рост будет спокойным и уверенным — десятки маленьких шагов в течение года выведут вас на новый уровень. Уделяйте больше времени спорту и друзьям, прокачивайте английский. Если вы сеньор — углубите навыки System design. ♐️ Стрелец (23 ноября — 21 декабря) Наступает период, когда пора применить все накопленные знания. А возможности для этого обязательно будут. Юпитер будет мешать делать важные задачи в срок, поэтому закладывайте на выполнение в 2 раза больше времени. При первой же возможности езжайте в заграничные путешествия. ♑️ Козерог (22 декабря — 19 января) Год будет положительным и стабильным. Если у вас есть какая-то тактика, придерживайтесь её. Если нет — составьте план развития на год. Подтяните тайм-менеджмент, иначе времени на хобби и внерабочие активности совсем не останется. ♒️ Водолей (20 января — 18 февраля) В год Тигра Водолеи нацелены на быстрый карьерный взлёт. Подтяните пробелы и обсудите с тимлидом возможности роста. Посмотрите вакансии, походите по собеседованиям. Вам нужна правильная почва для роста. Уделите больше внимания облачным технологиям. ♓️ Рыбы (19 февраля — 20 марта) В этом году удача не на вашей стороне, придётся много работать. Хотите успеха — начните сейчас, чтобы уже весной видеть первые результаты. Больше общайтесь с коллегами на неформальные темы, они отличные ребята В марте высокий риск простудиться, одевайтесь теплее. PS Я включила реакции, и спектр эмоций теперь шире. Но кнопку внизу пока оставила:)

Мой вариант — последний😊 Чищу мандаринки, смотрю статистику канала и радуюсь. Спасибо, что читаете нудные посты без картинок, помогаете найти ошибки и задаёте интересные вопросы. Благодаря вам канал живёт и развивается! Продолжим этот движ в 2022🚀

State of spring 2021 Поделюсь статистикой State of spring 2021 от VMWare. Данные релевантны для энтерпрайзных проектов из Европы и США. Сама статистика довольно скучная, поэтому дам небольшое овервью по некоторым модулям. 🔸 79% используют Spring Security в рабочих проектах 🔸 79% Spring Data Простые интерфейсы для работы с данными из разных БД. Обычно используется в связке с: ▫️ 78% JPA ▫️ 74% JDBC ▫️ 46% MongoDB ▫️ 37% Redis ▫️ 31% ElasticSearch 🔸 73% WebMVC 🔸 61% Boot 🔸 39% Kafka 🔸 38% Batch — фоновая обработка большого количества данных 🔸 37% Cloud Не смотрите на название, модуль используется не только в облачной инфраструктуре. Берёт на себя типовые задачи в микросервисной архитектуре: ▫️ Service Discovery — получить адрес другого сервиса ▫️ Добавить в логи информацию про конкретный сервис 🔸 35% WebFlux — поддержка реактивных библиотек 🔸 32% Integration Ещё один уровень абстракции и набор готовых компонентов, которые соединяются через Enterprise Integration Patterns. Через конфигурацию можно описать несложную логику вроде "прочитай XML, преврати в JSON, отправь по HTTP". 🔸 3% Native Компиляция и запуск на GraalVM. Уменьшает время старта и потребление памяти, хорошо работает с контейнерами. Большинство опрошенных в восторге от Native, но пока не торопятся внедрять в рабочий проект. Потому что Native пока в стадии бета и GraalVM слишком незрелая технология. Но 65% планируют использовать Native в будущем.