Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works

[Peter Levart]

Hi,

I think Daniel is talking about the "dispatch" semantics of 
unreflectSpecial here, right Daniel?

The findSpecial / unreflectSpecial is a MethodHandle equivalent for 
bytecode instruction invokespecial (sans actual invoking). invokespecial 
is typically used for implementing the super.method(args) Java 
invocations. In that case, the superclass method is targeted - this is 
not a virtual method dispatch like aMethod.invoke(this, arg*) - i.e. the 
reflective invocation is always a virtual invocation (for non-private 
methods). Likewise findSpecial and unreflectSpecial produce a 
MethodHandle that dispatches to the method in the superclass (the 
aMethod.getDeclatingClass() in case of unreflectSpecial) regardless of 
whether that method is overridden in the subclass or not.

Regards, Peter

On 7/30/19 4:47 PM, Mandy Chung wrote:
>
> Think about aMethod is a protected method inherited from its 
> superclass T.  To invoke aMethod, the receiver must be an instance of 
> T or a subclass of T.
>
> Mandy
>
> On 7/30/19 3:22 AM, Daniel Fuchs wrote:
>> Hi Mandy,
>>
>>  380      *     <th scope="row">{@link 
>> java.lang.invoke.MethodHandles.Lookup#unreflectSpecial 
>> lookup.unreflectSpecial(aMethod,this.class)}</th>
>>  381      *     <td>{@code T m(A*);}</td><td>{@code (T) 
>> aMethod.invoke(this, arg*);}</td>
>>
>> Is this exactly true? I mean - if `this` is an instance of
>> a subclass of `aMethod.getDeclaringClass()`, and if that
>> subclass overrides `aMethod`, then I would expect
>> `aMethod.invoke(this, arg*)` to execute the bytecode
>> of the method defined in the subclass.
>>
>> If I'm not mistaken, the test does expect that the
>> bytecode in the super class is executed instead.
>> I suspect that `unreflectSpecial` can only be specified
>> in terms of `findSpecial`. But maybe I'm missing something.
>> I'm not too familiar with the intricacies of MethodHandle.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 26/07/2019 18:41, Mandy Chung wrote:
>>> Daniel noticed that `unreflectSpecial` is missing in the "Lookup 
>>> Factory Methods" section in the class spec.  In fact there are a 
>>> duplicated `lookup.unreflect(aMethod)` row that might originally be 
>>> for `unreflectSpecial`.   I fix the javadoc in this patch:
>>>
>>> http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.01/
>>>
>>> Mandy
>>>
>>> On 7/25/19 1:12 PM, Mandy Chung wrote:
>>>> This patch fixes Lookup.unreflectSpecial to pass the declaring 
>>>> class of Method being unreflected (rather than null) so that it can 
>>>> accurately check if the special caller class is either the lookup 
>>>> class or a superinterface of the declaring class.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.00/index.html
>>>>
>>>> The test runs in both unnamed module and named module to cover 
>>>> JDK-8209078 which has been resolved by JDK-8173978.
>>>>
>>>> thanks
>>>> Mandy
>>>
>>
>