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

[Mandy Chung]

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
>>
>