[10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

[John Rose]

On Aug 24, 2017, at 1:13 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
>> 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).

That sounds right.  Please double check the corner case where A[] is int[].
In that case, a trailing String will fail to convert to int.  I think it will fail with CCE
on Integer.  IIRC, the actual decision logic is surprisingly subtle:  First you
have to see if the thing is a Byte, Short, or Character that can unbox and
then widen to int.  If that fails you blindly cast to Integer and unbox.
That boils down to CCE on Integer for something dumb like String.
If it's a null, you can get a NPE as the unbox fails on (Integer)null.

> 
>> 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.

The problem with asType is it is designed for valid JVM method type
signatures, including a limit of 255 argument slots.  I agree that the
new use of asType in a different context is slightly "off" and could
use refactoring.

— John