Thanks for the updates, Paul!

Some comments inlined.

On 23.08.2017 1:38, Paul Sandoz wrote:
First, implied `genericMethodType(N)` still fails with N > 255. It could safely 
be `genericMethodType(M)` though.

Well spotted! I tweaked it to:

* <li>Determine the general type {@code TN} of {@code N} arguments or
*     {@code M} arguments, if smaller than {@code N}, as
*     {@code TN=MethodType.genericMethodType(Math.min(N, M))}.</li>
Oh, right, `min(N, M)` should be better.
`M` could work as well (WMTE on arity mismatch would be thrown by `invokeExact` instead of `asType`),
but this way it's a bit easier to understand.
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`.

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.

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.

Thanks,
Stas

Reply via email to