[code-reflection] RFR: Invocation to vararg methods [v2]

[Maurizio Cimadamore]

On Tue, 10 Sep 2024 15:47:25 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 3789:
>> 
>>> 3787:      */
>>> 3788:     public static InvokeOp invoke(TypeElement returnType, MethodRef invokeDescriptor, List<Value> args) {
>>> 3789:         int paramCount = invokeDescriptor.type().parameterTypes().size();
>> 
>> I wonder if, for clients, it would be easier to use a descriptor for the non-varargs part, then specify a TypeElement for the varargs type, and let the API figure out how to wield those together. In a way the fact that "varargs are methods whose last parameter is an array" seems an impl detail?
>
> So split out the currently method reference into two parts? How would we resolve a varargs method from such a reference?
> 
> I was thinking, even though it makes no sense from a JLS perspective, that someone could interpret a method say `m(String s, List<String> more)` as a varargs method, where the variable arguments would somehow be "boxed" into a list rather than an array. That is possible to represent in the current design while the method reference is still resolvable.

Yeah - the fact that a `MethodRef` is basically bound to a symbolic reference is quite constraining here, as implementation details (varargs are arrays) end up leaking in the method ref. But that seems to be unavoidable to some extent.

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752945306