JDK7 language specification issue with MethodHandle

Neal Gafter neal at gafter.com
Tue Apr 5 07:47:55 PDT 2011

On Tue, Apr 5, 2011 at 7:00 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

>  On 04/05/2011 03:41 PM, Neal Gafter wrote:
> 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.

That's not what the JLS says.  The JLS precisely specifies which method is
to be called: MethodHandle.invokeExact(java.lang.Object[]):java.lang.Object,
typically (but not always) as a variable-arity invocation.

Because invokeExact() has a polymorphic signature, it can't be represented
> by a classical
> method in the bytecode.

The JLS doesn't have a concept of polymorphic signature in this sense.

 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.

The JLS doesn't say that this annotation may change compile-time behavior
otherwise specified by the JLS.


More information about the coin-dev mailing list