> On 23 Aug 2017, at 23:49, stanislav lukyanov <[email protected]>
> 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.
