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

[Daniel Fuchs]

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
>