invoke* on a MethodHandle

[Rémi Forax]

John Rose a écrit :
> On Feb 5, 2009, at 1:12 AM, Rémi Forax wrote:
>
>> By the way, the current prototype rely on getMethod (not 
>> getDeclaredMethod) to find callable methods,
>> so it's only possible to reify public methods.
>> Is it a known limitation of the current prototype or is the spec will 
>> only allow find* on public methods ?
>
> No, unless we run into technical problems or fundamental security 
> hazards, the JVM-level functionality should be able to ignore access 
> bits.  The access checking will be done at MH creation, as carefully 
> as necessary, but after that point all MHs are created equal.
>
>>> For convenient browsing and review, I have posted the javadoc 
>>> extracted from the current sources here:
>>>
>>> http://webrev.invokedynamic.info/jrose/6655638.meth.jdoc/
>>>
>>> This API is not yet official.  Comments would be welcome!
>> The doc of MethodHandle says it's possible to create a MethodHandle 
>> using a
>> LDC on Methodref/InterfaceMethodRef.
>>
>> "Bytecode in an extended JVM can directly obtain a method handle for 
>> any accessible method from a |ldc| instruction which refers to a 
>> |CONSTANT_Methodref| or |CONSTANT_InterfaceMethodref| constant pool 
>> entry. "
>>
>> What is the position of the JSR292 EG on this ?
>
> Nothing is decided yet on that, and that feature may drop away if 
> there's no demand for it.  But it is a very natural feature, from the 
> JVM perspective.
This is an official demand for this feature :)
as a language developer, it's important for me to be able to reference a 
MethodHandle
(think closure here) without generating lot of bytecodes.

It's exactly like the way ".class" is/was compile(d) by javac.
Until 1.5, ".class" was emulated by generating the same private method
on all toplevel class.
If we don't have LDC MethodHandle, we (all language developers)
will rely on a private method that create a MethodType and
call a MethodHandles.find*.

>
> -- John
Rémi