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

[Daniel Fuchs]

Hi Peter, Mandy,

On 31/07/2019 09:44, Peter Levart wrote:
> Expanding on this a little. The javadocs of MethodHandles.Lookup starts 
> talking about the Lookup factory methods methods and their equivalence 
> to bytecode instructions, but then present the equivalence between find* 
> and Java source code (which is OK given that translation to bytecode is 
> known) followed by equivalence between unreflect* and reflective 
> invocations. Public reflection API does not implement the equivalent 
> behavior to unreflectSpecial. So perhaps, this line only could present 
> the equivalence in terms of Java code like findSpecial does with a 
> comment stating that there's no equivalence with reflective invocation 
> API. For example:
> 
>       * <tr>
>       *     <th scope="col"><a id="equiv"></a>lookup expression</th>
>       *     <th scope="col">member</th>
>       *     <th scope="col">bytecode / reflection behavior</th>
> 
> Added "/ reflection" above; and:
> 
>       * <tr>
>       *     <th scope="row">{@link 
> java.lang.invoke.MethodHandles.Lookup#unreflectSpecial 
> lookup.unreflectSpecial(aMethod,this.class)}</th>
>       *     <td>{@code T m(A*);}</td><td>{@code (T) super.m(arg*); // no 
> equivalent reflective invocation}</td>
>       * </tr>

Yes - I would find this description better.
Additionally maybe it could say that the MH returned is
equivalent to that returned by `findSpecial(aMethod.getDeclaringClass(), 
aMethod.getName(), MT, this.class)` - as there's no reflection equivalent?

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

Ah - that's a very good explanation for the nature of the fix itself.
Thanks for that! But my comment was about virtual vs special invocation 
as Peter noted.

best regards,

-- daniel