Spread problem with > 10 arguments

[Rémi Forax]

Fredrik Öhrström a écrit :
> Rémi Forax skrev:
>   
>> Your implementation doesn't follow the spec :
>> http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/java/dyn/MethodHandles.html#collectArguments(java.dyn.MethodHandle,%20java.dyn.MethodType)
>>
>> Only trailing arguments for a given position are collected :
>> http://code.google.com/p/jvm-language-runtime/source/browse/trunk/invokedynamic-backport/src/jsr292/java/dyn/MHCollecter.java
>>
>> So it grows quadratically or you have to create on class by collect 
>> position.
>>   
>>     
> You are right that it does not follow the spec. However you can easily 
> implement adapters that
> grow linearly and follow the spec. :-) How about this: (target and 
> position are declared final of course)
>
> public Object adapt3(Object a, Object b, Object c)
> {
>     int i = 0;
>     Object[] spread = new Object[3-position];
>     switch (position) {
>           case 0: spread[i++] = a;
>           case 1: spread[i++] = b;
>           case 2: spread[i++] = c;
>     }
>     switch(position) {
>         case 0:  return target.invoke<Object>(spread);
>         case 1:  return target.invoke<Object>(a, spread);
>     }
>     return target.invoke<Object>(a, b, spread);
> }
>
> It should be alright to use 256 internal classes as well. It is still
> a small and finite number that will never grow. :-)
>   

It's better than my code :)

>> It's not a simple change because  between the call site  and the target
>> method you have a bunch of adapters.
>> generic invocation means two different paths between the call site and
>> the target method because when the target method is reached
>> the former will just call the target method and the later will have to
>> do some checkcasts before calling the method.
>>
>> Maintaining these two paths is practicable but not simple.
>>   
>>     
> I do not understand why you should have to maintain two paths.
> Please explain a bit more!
>   

If you have only one path, the method-type check is useless
because you will do the check casts too.

>> you mean WrongMethodTypeException :)
>>   
>>     
> Yes! Thanks!
>
> //Fredrik
>   
Rémi