New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Rémi Forax" <forax at univ-mlv.fr>
> Cc: "Andrew Dinn" <adinn at redhat.com>, jigsaw-dev at openjdk.java.net
> Envoyé: Samedi 12 Novembre 2016 04:23:13
> Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules &
> open packages

> On Nov 11, 2016, at 7:09 AM, forax at univ-mlv.fr wrote:

>> MH.invokeWithArguments takes an array of arguments but because it is specified
>> as a varargs you may think that it works like Method.invoke, but it is a trap,
>> it takes the receiver and the arguments altogether into the same array.

> Thanks, Remi. That should fix the problem.

> We thought a little bit about adding more overloadings to invokeWithArguments,
> such as one that works like Method.invoke (one prepended argument).
> The general case would be making invokeWithArguments be signature-polymorphic,
> with an on-the-fly asSpreader transform on the way through.

> But, such extra generality would simplify only a few use cases, and on the
> other hand it would probably create plenty of confusion whenever the target
> method is *also* a varargs method.

The other solution is to have another non-polymorphic invoke method, invokeVirtualWithArguments that takes an instance and an array of objects like Method.invoke. But in my opinion, Method.invoke is a weird legacy format for a method call, separating the receiver from the other arguments is not natural for the VM, so this format should not have its own invoker. That said, it may help to rewrite the implementation of the reflection API to use method handles under the hood in order to remove the dedicated bytecode generator used by the current implementation. 

> — John

Rémi