MethodHandle - для чего он нужен?

Я изучаю новые возможности JDK 1.7 и просто не могу понять, для чего предназначен MethodHandle? Я понимаю (прямое) обращение к статическому методу (и использование Core Reflection API, что в данном случае прямолинейно). Я также понимаю (прямое) обращение к виртуальному методу (нестатическому, нефинальному) (и использование Core Reflection API, которое требует прохождения по иерархии класса obj.getClass().getSuperclass()). Вызов невиртуального метода можно рассматривать как частный случай первого.

Да, я знаю, что есть проблема с перегрузкой. Если вы хотите вызвать метод, вы должны предоставить точную сигнатуру. Вы не можете проверить наличие перегруженного метода простым способом.

Но для чего нужен MethodHandle? API Reflection позволяет вам "заглянуть" во внутренности объекта без каких-либо предварительных предположений (типа реализован интерфейс). Вы можете исследовать объект для какой-либо цели. Но для чего же предназначен MethodHandle? Зачем и когда я должен его использовать?

UPDATE: Сейчас я читаю эту http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html статью. Согласно ей, основная цель - упростить жизнь скриптовым языкам, которые работают поверх JVM, а не самому языку Java.

UPDATE-2: Дочитал ссылку выше, некоторые цитаты оттуда:

JVM будет лучшей VM для создания динамических языков, потому что она уже является VM для динамических языков. И InvokeDynamic, продвигая динамические языки к первоклассным гражданам JVM, докажет это.

Использование отражения для вызова методов работает отлично... за исключением нескольких проблем. Объекты методов должны быть получены из определенного типа и не могут быть созданы общим способом.<...>

...отраженный вызов намного медленнее прямого вызова. За прошедшие годы JVM очень хорошо справилась с тем, чтобы сделать отраженный вызов быстрым. Современные JVM фактически генерируют кучу кода за сценой, чтобы избежать многих накладных расходов, с которыми сталкивались старые JVM. Но простая истина заключается в том, что отраженный доступ через любое количество уровней всегда будет медленнее, чем прямой вызов, частично потому, что полностью сгенерированный метод "invoke" должен проверять и перепроверять тип приемника, типы аргументов, видимость и другие детали, а также потому, что все аргументы должны быть объектами (поэтому примитивы становятся объектно-блочными) и должны быть предоставлены в виде массива, чтобы охватить все возможные степени (поэтому аргументы становятся массивно-блочными).

Разница в производительности может не иметь значения для библиотеки, выполняющей несколько отраженных вызовов, особенно если эти вызовы в основном предназначены для динамической установки статической структуры в памяти, к которой она может выполнять обычные вызовы. Но в динамическом языке, где каждый вызов должен использовать эти механизмы, это сильно снижает производительность.

http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

Таким образом, для Java-программиста это по сути бесполезно. Я прав? С этой точки зрения, его можно рассматривать только как альтернативный способ для Core Reflection API.