Я изучаю новые возможности JDK 1.7, и я просто не могу понять, для чего предназначен MethodHandle. Я понимаю (прямой) вызов статического метода (и использование Core Reflection API, который в этом случае является простым). Я также понимаю (прямой) вызов виртуального метода (нестатического, не финального) (и использование API Core Reflection, требующего прохождения иерархии классов obj.getClass().getSuperclass()). Вызов не виртуального метода можно рассматривать как частный случай первого.
Да, я знаю, что есть проблема с перегрузкой. Если вы хотите вызвать метод, вы должны указать точную подпись. Вы не можете легко проверить перегруженный метод.
Но что такое MethodHandle? API Reflection позволяет вам "просматривать" внутренние объекты без каких-либо предварительных допущений (например, реализованный интерфейс). Вы можете осмотреть объект для какой-либо цели. Но что же такое MethodHandle? Почему и когда я должен использовать его?
ОБНОВЛЕНИЕ: Я читаю эту статью http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html. Согласно этому, главная цель - упростить жизнь для языков сценариев, которые работают поверх JVM, а не для самого языка Java.
UPDATE-2: Я заканчиваю читать ссылку выше, некоторые цитаты оттуда:
JVM станет лучшей виртуальной машиной для создания динамических языков, поскольку она уже является динамической виртуальной машиной. И InvokeDynamic, продвигая динамические языки для первоклассных граждан JVM, докажет это.
Использование методов отражения для вызова отлично работает... за исключением нескольких проблем. Объекты метода должны извлекаться из определенного типа и не могут быть созданы в общем виде. <... >
... отраженный вызов намного медленнее, чем прямой вызов. На протяжении многих лет JVM отлично справлялся с тем, чтобы сделать обратный вызов быстрым. Современные JVM на самом деле генерируют кучу кода за кулисами, чтобы избежать значительных проблем со старыми JVM. Но простая истина заключается в том, что отраженный доступ через любое количество уровней всегда будет медленнее прямого вызова, частично потому, что полностью генерализованный метод "invoke" должен проверять и повторно проверять тип приемника, типы аргументов, видимость и другие данные, но также потому, что аргументы должны быть объектами (поэтому примитивы получают объект-бокс) и должны быть представлены как массив для охвата всех возможных явлений (поэтому аргументы получают массив-boxed).
Разница в производительности может не иметь значения для библиотеки, выполняющей несколько отраженных вызовов, особенно если эти вызовы состоят в основном для динамической настройки статической структуры в памяти, с которой она может выполнять обычные вызовы. Но на динамическом языке, где каждый вызов должен использовать эти механизмы, это серьезный удар по производительности.
http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html
Итак, для Java-программиста это бесполезно. Я прав? С этой точки зрения, это можно рассматривать только как альтернативный способ для API Core Reflection.
