Question About MethodHandles.findSpecial

[John Rose]

On May 5, 2009, at 12:25 PM, Fredrik Öhrström wrote:

>> or invocation of private methods, see section 7.7 of the JVM spec.
>> Rémi
>
> Thanks! A MethodHandle pointing to a private method makes sense.
> Still the javadoc for findSpecial explicitly mentions the  
> constructor so
> is there any reason for executing a constructor through a  
> MethodHandle?

Well, there is a strong reason for method invocation via  
invokespecial.  To avoid burdensome workarounds, you need it if your  
dynamic language is going to extend Java classes.  The topic was  
discussed on jvm-languages:
   http://groups.google.com/group/jvm-languages/browse_thread/thread/319982bfe1be9487/

That conversation is one of the reasons we have  
MethodHandles.findSpecial.

The same points apply, slightly less forcefully, to invokspecial of  
constructors.  One design goal with JSR 292 is to avoid forcing  
dynamic languages to generate bytecodes for at cut points:  That's why  
method handles have method handles for private access, field access,  
and invokespecial (smalltalk sendsuper).

The other goal, of course, is to make bytecode generation, when the  
implementor *chooses* to use it, to be much more profitable, because  
invokedynamic lets you punch through to the virtual metal.

> Also, what is the reason for the specialCaller argument? (Also  
> referred
> to as caller in the javadoc.)

Since findSpecial creates a method handle which emulates an  
invokespecial instruction, we have to perform the access checks that  
pertain to that instruction.

If a privileged module (like a language runtime) is calling  
findSpecial, we still want to make access checks for invokespecial  
against the logical caller of the invokespecial instruction, not  
against the runtime.  (There may be another reason, which I'm not  
remembering... I'm a little sleep-deprived from the M3 push.)  I  
suppose that reasoning applies to any lookup, not just findSpecial.

The latest API factors the access checks more explicitly (into a  
"Lookup" capability object), so perhaps we can clean this up.  Instead  
of calling MethodHandles.findVirtual, you call MethodHandles.lookup()  
(yielding a Lookup object, which is your factory) and then call  
lookup.findVirtual.  The lookup guy authenticates the caller, and then  
can be used for several lookups from the same caller, or handed off  
from the caller to a trusted delegate (like a runtime).

-- John