JDK7 language specification issue with MethodHandle
forax at univ-mlv.fr
Tue Apr 5 07:00:39 PDT 2011
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<
> > 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
> > considered a clear violation of Java trademark licensing
> 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
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
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.
More information about the coin-dev