Андрей Беляев про рефлексию в Java на встрече jug.msk.ru

[PqDn]

Только я один про рефлексию в статье ничего не увидел?

[dbelob]

Имеется возможность полистать презентацию, посмотреть видео предыдущего короткого варианта доклада (видео текущего появится здесь чуть позднее), посмотреть код и задать a_belyaev вопросы — думаю, Андрей на на них с удовольствием ответит.

[pjBooms]

a_belyaev, вот сколько можно все-таки повторять миф — «Reflection — нет AOT компиляции»?
Reflection совершенно не противоречит AOT компиляции. Можете по этому поводу посмотреть мой доклад про «AOT компиляцию SpringBoot», где я эту тему разжевал как никогда ранее подробно. Все чему противоречит Reflection — это AOT-компиляции Java приложений в предположении закрытости мира — в присутствии reflection теоретически нельзя определить границы закрытого мира. И уменьшение рефлексии этой проблеме не очень помогает: пока рефлексия есть и используется, закрывать мир — небезопасно, а значит имеет мало смысла с практической точки зрения

[a_belyaev]

Привет, спасибо за комментарий, я смотрел вот это видео. Мне точно надо как-то все-таки правильнее и яснее выражаться. AOT компиляция и reflection не противоречат друг другу, но в случае их совместного использования все становится немного сложнее. Можно нормально скомпилировать приложение, которое использует reflection. Какие-то классы, которые используются через reflection, можно вывести автоматически, какие-то — явно вписать в конфигурационные файлы и скормить эти файлы компилятору (если мы говорим о GraalVM компиляторе), где-то — угадать, какая будет логика загрузки классов в рантайме после старта программы. Мое мнение — на сложных приложениях такой подход будет давать сбои, учитывая, сколько сторонних библиотек мы с собой обычно тащим явно и неявно, в которых может быть вообще что угодно. Простой пример: аккуратно собранный Spring Context, ничего лишнего, компилятор все отлично собирает. Но вот в случае запуска через

java -jar

все прекрасно работает, а в случае запуска native image работает не все. И это обозримый код. Конечно, это больше говорит о недостатках GraalVM, но, тем не менее, в связи с переездом Excelsior под крыло Huawei, этот компилятор остается чуть не единственным вариантом для тех, кто хочет работать с AOT в java.

[pjBooms]

Проблема GraalVM native image — это closed world assumption, когда сразу предполагается, что в рантайме мы ничего нового грузить не будем, а что вообще в принципе будем, вычисляем через замыкание потока управления. Этому подходу очевидно мешает и reflection и динамическая загрузка — статически замкнуть в присутствии reflection — невозможно. У Excelsior JET то же был давно (15 лет назад) оптимизатор на основе предположения замкнутости мира. Практика показала, что подход совршенно нежизнеспобоный для Java — ваши примеры в этом коментарии это наглядно показывают, только это было известно еще 15-20 лет назад. Однако AOT может жить и не полагаясь на CWA, давая сравнимые результаты с CWA по стартапу и футпринту с одной стороны, а с другой полностью соответсвуя спецификации ( то есть и рефлексия и динамическая загрузка — просто работают без всяких конфигурационных файлов). Возвращаясь к вашей презентации — предлагаю переформулировать тезис — «Reflection — нет AOT компиляции», в „Reflection — нельзя замкнуть мир заранее (плохо работает GraalVM native image)“.

[a_belyaev]

Да, справедливо. Если буду делать читать этот доклад ещё раз, то так и переформулирую. И попутно вкручу соображения про CWA. Excelsior — это здорово, но теперь же не загрузишь же дистрибутив с официального сайта. Если только по знакомым и третьесторонним файлопомойкамхранилищам искать :-)