Комментарии 3
Решив проблемы рефлексии, MethodHandle API стал не её заменой, а альтернативой, позволяющей оптимизировать динамические операции. Его основное преимущество в контексте вызовов — интеграция с JVM через
invokedynamic
, позволяющая JIT применять оптимизации. После прогрева#invokeExact
и#invoke
работают примерно в 2 раза быстрее рефлексии, хотя и остаются в 7 раз медленнее прямых вызовов.
но в Java 18 прилетел и теперь рефлексия сама работает поверх метод хендлов =) но оригинальное апи конечно же оставили. где-то стало быстрее с новой реализацией, где-то медленнее
JEP 416: Reimplement Core Reflection with Method Handles
Summary
Reimplement java.lang.reflect.Method
, Constructor
, 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 не означает, что проверки которые делаются на уровень выше куда-то исчезнут
Method Handles быстрее рефлексии (иногда)