[10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

Paul Sandoz paul.sandoz at oracle.com
Thu Aug 24 19:34:21 UTC 2017

> On 24 Aug 2017, at 11:51, John Rose <john.r.rose at oracle.com> wrote:
> On Aug 24, 2017, at 1:13 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto: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[].

We are on the same page, already did :-)

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

Yes, FWIW it fails trying to cast it to Number, that’s just an implementation detail (since prior checks deal with Boolean and and Character and further checks deal with primitive to primitive number conversion).

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

Yes. I suppose i should add NPE to be complete:
*     <li>If any of these conversions proves impossible, fail with either
*         a {@code ClassCastException} if any trailing element cannot be
*         cast to {@code A} or a {@code NullPointerException} if any
*         trailing element is {@code null} and {@code A} is not a reference
*         type. </li>
If the sequence of trailing elements can induce both exceptions then which one is thrown is unspecified i.e. i really don’t wanna get in the order of processing the trailing elements.


More information about the core-libs-dev mailing list