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
