Hi Peter, On 4/4/20 3:58 AM, Peter Levart wrote:
Here I think, you are not quite right. First I need to clarify that we are talking about the case where the method reference in above example is not converted to lambda by javac, so the proxy class needs to invoke the superclass method directly (without the help of lambda bridge). I did an experiment and compiled the example with JDK 13 javac, where the patch for (JDK-8234729) is not applied yet. What I get from this compilation is the following metafactory bootstrap method invocation:
0: #35 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; Method arguments: #42 ()V #43 REF_invokeVirtual test/LambdaTest.m:()V #42 ()V
The #43 is the implMethod method handle and it is the following:
#43 = MethodHandle 5:#44 // REF_invokeVirtual test/LambdaTest.m:()V #44 = Methodref #2.#45 // test/LambdaTest.m:()V #45 = NameAndType #46:#6 // m:()V #46 = Utf8 m #2 = Class #4 // test/LambdaTest #4 = Utf8 test/LambdaTest
*BUT* the class that looks up this MH from the constant pool is the subclass (test.sub.LambdaTestSub) which is equivalent to the following programmatic lookup:
var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, "m", MethodType.methodType(void.class)); System.out.println(mh.type());
and this results in a method handle of the following type: (LambdaTestSub)void
which is correct since the method handle *MUST* check that the passed in instance (this) is of type LambdaTestSub or subtype or else the "protected" access would be violated.
And since the ref type is REF_invokeVirtual, the AbstractValidatingLambdaMetafactory assigns the following to the implClass:
this.implMethodType = implMethod.type(); this.implInfo = caller.revealDirect(implMethod); switch (implInfo.getReferenceKind()) { case REF_invokeVirtual: case REF_invokeInterface: this.implClass = implMethodType.parameterType(0);
...which makes the implClass be LambdaTestSub in this case. Which is correct again since we want InnerClassLambdaMetafactory to decide that this is the special case for proxy to invoke the method via method handle:
useImplMethodHandle = !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) && !Modifier.isPublic(implInfo.getModifiers());
If implClass was test.LambdaTest as you said above, this condition would evaluate to false, since implInfo is "invokeVirtual test.LambdaTest.m:()void" in above case.
My bad. I mixed up with implClass and implInfo cracked from implMethod in your question. implInfo::getDeclaringClass() returns the declaring class of the resolved method, which is the superclass (which is what I have been thinking for test.LambdaTest). implClass is the target type of the method reference. AbstractValidatingLambdaMetafactory has clear comment: final MethodType implMethodType; // Type of the implMethod MethodHandle "(CC,int)String" final Class<?> implClass; // Class for referencing the implementation method "class CC"
So everything is OK, but my original question was the following: The name of the generated proxy class is derived from the targetClass which is the caller's lookup class. In this example the caller is LambdaTestSub and this is the same as implClass in this case.
Yes.
Would those two classes always be the same in the case where the evaluation of the above `useImplMethodHandle` boolean matters? I mean, the decision about whether to base the proxy invocation strategy on method handle or direct bytecode invocation is based on one class (implClass), but the actual package of the proxy class which effectively influences the bytecode invocation rights is taken from another class (targetClass).
On one hand the package of the proxy class has to be the same as targetClass if the proxy wants to be the nestmate of the targetClass (for example to have private access to the members of the nest). But OTOH it needs to be the same package also with implClass so that the above decision of the proxy invocation strategy is correct. I have a feeling that for protected virtual methods, this is true, because the type of the 0-argument of such method handle is always the lookup class. But am I right?
What do you think of another alternative to invoking the super protected method in other package: What if the LMF would decide to base the name of the proxy class on the implInfo.getDeclaringClass() in such case? It would not have to be a nestmate of any class, just in the same package with the method's declaring class. Consequently it would be in the same module as the declaring class and loaded by the same class loader. Therefore it would have to be WEAKLY referenced from the class loader. And the Lookup instance passed to bootstrap LMF method would not be enough for defining such class. But LMF could obtain special powers since it is JDK internal class...
The implementation of the method reference invocation is logical part of the caller class. I don't think spinning the proxy class in a remote package is the desirable thing to do (injecting a class from package A to package B).
Well, I don't know for myself. Is this situation rare enough so that invoking via method handle is not a drawback? It only happens when running JDK 13- compiled classes with JDK 15+ and in addition the method reference must point to protected method in a distant class.
There are other alternatives we considered. This implementation is a just short term solution. We plan to follow up some future enhancements that are the possible longer-term solutions for this issue. 1. JDK-8239580 evaluate the performance of direct method handle invocation rather than bytecode invocation for ALL cases Direct invocation of the `implMethod` method handle by the lambda proxy was explored in JDK 8 lambda development time. It is time to remeasure the performance of direct method handle invocation and re-evaluate that approach. 2. JDK-8230501 class data support. The live MethodHandle can be passed to the hidden class to replace the current implementation to set the implMethod in a static field of proxy class after it's defined. 3. JDK-8199386 enhance Lookup::in to support nestmates Hope this helps. Mandy