Suggestion (Re: A pure Java example with reflective access behaving differently with invokeWithArguments() compared to core reflection's invoke() (Re: Strange observation: MethodHandle.invokeWithArguments() would not work, whereas Method.invoke() would with the very same arguments

[Rony G. Flatscher]

On 10.06.2018 17:04, Peter Levart wrote:
... cut ...

> So if you want HM.invokeWithArguments() to behave the same as Method.invoke(), you have to
> transform the method handles obtained from lookup / unreflect with MH.asFixedArity() method. If
> the method handle is already a fixed arity method handle, this method will just return it, else it
> will return the equivalent method handle that doesn't perform collection of trailing positional
> arguments into an array argument. Using MH.asFixedArity() on each and every method handle you
> obtain by unreflect should give you the same behavior of MH.invokeWithArguments() as using
> Method.invoke().
... cut ...


On 11.06.2018 16:37, Rony G. Flatscher wrote:
... cut ...

> Indeed, this seems to solve the problem, which is really great as this problem can be put to rest
> and it makes it safe to use MH invocations in the bridge from Java 8 on!
>
> Thank you *very* much again!
> (And now, "after the fact" of your explanations I have become able to understand the cause of the
> problem and its solution. I simply was not aware that by default a varargs collector would be
> employed for the last (in this case single) argument for a varargs argument.)
... cut ...


On 10.06.2018 14:16, Rony G. Flatscher wrote:
... cut ...

> A few coarse ideas to address this:
>
>   * if the unreflect() method gets used then MH.invoke() should behave like in the
>     java.lang.reflect case; this means that the same assumptions should govern MH.invoke(): reason
>     being that if a java.lang.reflect object gets unreflected, also the established
>     java.lang.reflect rules should keep working in this case for the MH.invoke* in order to remain
>     fully compatible with each other,
>       o if a MH gets created without unreflect() then this would not be necessary
>
... cut ...

The suggestion would be to have unreflect() apply MH.asFixedArity() such that the MH behaves as
c.l.r invoke.

---rony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20180612/e6b194f7/attachment.html>