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

Daniel Fuchs daniel.fuchs at
Tue Jul 30 10:22:10 UTC 2019

Hi Mandy,

  380      *     <th scope="row">{@link 
  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:
> 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:
>> The test runs in both unnamed module and named module to cover 
>> JDK-8209078 which has been resolved by JDK-8173978.
>> thanks
>> Mandy

More information about the core-libs-dev mailing list