JDK7 language specification issue with MethodHandle

[Rémi Forax]

On 04/05/2011 03:41 PM, Neal Gafter wrote:
> On Tue, Apr 5, 2011 at 1:24 AM, Rémi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>
>     On 04/05/2011 06:57 AM, Neal Gafter wrote:
>     > The documentation for MethodHandle (see "Method Handle
>     Compilation" in<
>     >
>     http://download.java.net/jdk7/docs/api/java/lang/invoke/MethodHandle.html>)
>     > appears to contradict the requirements of the Java Language
>     Specification by
>     > describing compiler behavior that does not conform to the
>     requirements of
>     > the JLS.  I have not checked, but I would not be surprised if
>     jdk7's javac
>     > also fails to satisfy the specification in this area.  This is
>     the kind of
>     > backdoor language change that Java's corporate owner has
>     consistently
>     > considered a clear violation of Java trademark licensing
>     requirements.
>
>     I don't understand exactly what you mean.
>     Coud you be a little more specific ?
>
>
> I'm referring to requirements such as not boxing primitives, not 
> building a varargs array, and producing the "wrong" method signature 
> in the invoke instruction.  The binary compatibility section of the 
> JLS specifies what method signature to be generated in the invocation, 
> and this documentation specifies another.

Ok, let step back a moment.
When you do a MethodHandle.invokeExact() the compiler has no idea of the 
target method
so it can't do any conversions like boxing or varargs.
Because invokeExact() has a polymorphic signature, it can't be 
represented by a classical
method in the bytecode.

But, it has been chosen to have a corresponding invokeExact() in the 
class MethodHandle.
This method is not the real invokeExact() but more a placeholder for 
documentation.
The method invokeExact() in the bytecode is annotated with an annotation 
saying
that the compiler should not care about the signature of this method but
should build the method descriptor based on the type of the argument and
the type of the cast (or void for statement) for the return type.

Rémi