| Other |
|---|
| tbdUnresolved |
|
Blocks :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
MethodHandle lookups mimic the JVM's method resolution behavior (JVMS 5.4.3.3). This involves taking a *referenced* class and a method name/descriptor, and returning a *declared* class and method. Often, the declaring class is a supertype of the referenced class, rather than being the same as the referenced class.
MethodHandleInfo provides getDeclaringClass, but does not have any way to get the referenced class.
Example:
import java.lang.invoke.*;
public class MethodHandleInfoTest {
public static void main(String... args) throws Exception {
MethodHandles.Lookup l = MethodHandles.lookup();
MethodHandle mh = l.findVirtual(MethodHandleInfoTest.class, "toString", MethodType.methodType(String.class));
MethodHandleInfo info = l.revealDirect(mh);
System.out.println(info.getDeclaringClass()); // declaring class
System.out.println(info.???); // referenced class
}
}
The referenced class is important, because i) the mapping from a referenced class to a declaring class is nondeterministic if there are multiple superinterfaces that declare equivalent methods (the VM may pick any one superinterface); ii) access restrictions on the declaring class may be different than access restrictions on the referenced class.
Concretely, for example, an implementation of LambdaMetafactory may wish to serialize a MethodHandle in bytecode. In order to avoid access problems, this serialized form needs to name the referenced class, not the declaring class.
|