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

Paul Sandoz psandoz at openjdk.org
Tue Sep 10 20:58:01 UTC 2024


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

>> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 1519:
>> 
>>> 1517:             HashMap<String, Object> m = new HashMap<>(super.attributes());
>>> 1518:             m.put("", invokeDescriptor);
>>> 1519:             if (isVarArgs) {
>> 
>> This seems a bit of an arbitrary cut - e.g. we only generate as few attributes as possible, given we know how to infer some of those. I understand why: we don't want invoke ops to look to scary in the string representation...
>> 
>> Why do we need to emit the invokekind for variadic calls?
>
> We don't need to in all cases - only required for super invocations. I just chose a path of least resistance when hacking it together. My main motivation was to avoid updating all the tests! Varargs calls are less common so I was not overly concerned about the scary strings.
> 
> But, for consistency I think it is worth addressing this. If `invoke.varargs` is present and `invoke.kind` is not we can infer static or instance invocation.

Actually there was a reason, that i forgot about. Let's say we have a method `A::m(A... more)` we know it is varargs but don't know if it's a static or instance method. Given one operand we cannot differentiate between `a.m()` and `m(a)`.

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

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


More information about the babylon-dev mailing list