[code-reflection] RFR: Invocation to vararg methods

[Paul Sandoz]

On Tue, 10 Sep 2024 14:50:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
>> 
>> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
>> 
>> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).
>
> 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.

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

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