JDK7 language specification issue with MethodHandle
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
> This method is not the real invokeExact() but more a placeholder for
> The method invokeExact() in the bytecode is annotated with an annotation
> 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