Все потоки
Поиск
Написать публикацию
Обновить

Комментарии 3

Решив проблемы рефлексии, MethodHandle API стал не её заменой, а альтернативой, позволяющей оптимизировать динамические операции. Его основное преимущество в контексте вызовов — интеграция с JVM через invokedynamic, позволяющая JIT применять оптимизации. После прогрева #invokeExact и #invoke работают примерно в 2 раза быстрее рефлексии, хотя и остаются в 7 раз медленнее прямых вызовов.

но в Java 18 прилетел и теперь рефлексия сама работает поверх метод хендлов =) но оригинальное апи конечно же оставили. где-то стало быстрее с новой реализацией, где-то медленнее

https://openjdk.org/jeps/416

JEP 416: Reimplement Core Reflection with Method Handles

Summary

Reimplement java.lang.reflect.MethodConstructor, and Field on top of java.lang.invoke method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the java.lang.reflect and java.lang.invoke APIs.

Non-Goals

It is not a goal to make any change to the java.lang.reflect API. This is solely an implementation change.

Спасибо за замечание! (и за ссылку на JEP) Этот момент прошёл мимо меня во время исследования.
Довольно интересно, что решили использовать под капотом рефлексии метод хендлы. Но всё-таки стоит отметить, что это не сравнится по скорости с прямым использованием MethodHandle =(. Это подтвержается и результатами бенчмарка

MethodHandles - проверка доступов в момент создания, в последующем проверок нету

Reflection - проверки доступов на каждом вызове, что ожидаемо будет дороже, чем больше вызовов вы делаете. то что под капотом теперь используется MethodHandles не означает, что проверки которые делаются на уровень выше куда-то исчезнут

Зарегистрируйтесь на Хабре, чтобы оставить комментарий