[10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

[Paul Sandoz]

> On 23 Aug 2017, at 23:49, stanislav lukyanov <stanislav.lukyanov at oracle.com> wrote:
> 
> Thanks for the updates, Paul!

>>> Second, it's unfortunate that varargs collection has to be re-implemented in the spec
>>> for `invokeWithArguments` instead of reusing what `asVarargsCollector` has.
>> I think this was always the case, but it has become more apparent with what is more clarification than arguably necessary to overcome the argument limitation. There is of course some notable differences between invokeWithArguments and invoke/invokeExact.
> Well, before this patch `invokeWithArguments` didn't itself specify any varargs processing, just referred to `asType`.
> 

Yes, because previously it did not need to overcome the argument limitation.


> There seems to be one more issue:
> > <li>Collect the trailing elements (there are {@code N-M+1} of them)
> > from the logical argument list into a single array of
> > type {@code A[]}, using {@code asType} conversions to
> > convert each trailing argument to type {@code A}. </li>
> > <li>If any of these conversions proves impossible, fail with a
> > {@code WrongMethodTypeException}. </li>
> `asType(genericMethodType(N)).invokeExact(...)` would throw CCE, not WMTE.
> At link-time it would only see `Object` types which never fail to be collected to varargs, so no WMTE.
> At run-time, the casts may fail producing ClassCastException.
> 

Well spotted, yes, that should be ClassCastException. The asType transformation is rather selective of when it throws WMTE (for non-matching arity and impossible primitive conversions).


> I still think that instead of debugging this spec and making sure that it behaves similarly to `asType`
> it would be better to keep delegating to the implied `asType` and allow it not to throw IAE for too many parameters.
> 

I actually prefer the explicit approach here, rather than re-purposing asType and by extension asVarargsCollector (“as if by asType but …”), but i do take your point (IIRC) that the specification of asVarargsCollector could duplicate some common specification text.

Paul.