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.


mlvm-dev mailing list

Reply via email to