title: MethodHandle - What is it all about?
body: <p>I am studying new features of JDK 1.7 and I just can't get it what MethodHandle is designed for? I understand (direct) invocation of the static method (and use of Core Reflection API that is straightforward in this case). I understand also (direct) invocation of the virtual method (non-static, non-final) (and use of Core Reflection API that requires going through Class's hierarchy <code>obj.getClass().getSuperclass()</code>). Invocation of non-virtual method can be treated as special case of the former one.</p>
  <p>Yes, I aware that there is an issue with overloading. If you want to invoke method you have to supply the exact signature. You can't check for overloaded method in easy way.</p>
  <p>But, what is MethodHandle about? Reflection API allows you to &quot;look on&quot; the object internals without any pre-assumption (like implemented the interface). You can inspect the object for some purpose. But what is MethodHandle is designed too? Why and when should I use it?</p>
  <p><strong>UPDATE:</strong> I am reading now this <a href="http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html" rel="nofollow noreferrer">http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html</a> article. According to it, the main goal is to simplify life for scripting languages that runs atop of JVM, and not for Java Language itself.</p>
  <p><strong>UPDATE-2:</strong> I finish to read the link above, some quotation from there:</p>
  <blockquote>
  <p>The JVM is going to be the best VM for building dynamic languages, because it already is a dynamic language VM. And InvokeDynamic, by promoting dynamic languages to first-class JVM citizens, will prove it.</p>
  <p>Using reflection to invoke methods works great...except for a few problems. Method objects must be retrieved from a specific type, and can't be created in a general way.&lt;...&gt;</p>
  <p>...reflected invocation is a lot slower than direct invocation. Over the years, the JVM has gotten really good at making reflected invocation fast. Modern JVMs actually generate a bunch of code behind the scenes to avoid a much of the overhead old JVMs dealt with. But the simple truth is that reflected access through any number of layers will always be slower than a direct call, partially because the completely generified &quot;invoke&quot; method must check and re-check receiver type, argument types, visibility, and other details, but also because arguments must all be objects (so primitives get object-boxed) and must be provided as an array to cover all possible arities (so arguments get array-boxed).</p>
  <p>The performance difference may not matter for a library doing a few reflected calls, especially if those calls are mostly to dynamically set up a static structure in memory against which it can make normal calls. But in a dynamic language, where every call must use these mechanisms, it's a severe performance hit.</p>
  </blockquote>
  <p><a href="http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html" rel="nofollow noreferrer">http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html</a></p>
  <p>So, for Java programmer it is essentially useless. Am I right? From this point of view, It can be only considered as alternative way for Core Reflection API.</p>
  <p><strong>UPDATE-2020:</strong> Indeed, MethodHandle can be thought as s more powerful alternative to Core Reflection API. Starting with JDK 8 there are also Java Language features that use it.</p>