Hi Rony,
I showed you some code samples in Java language, so I had to explain
what java compiler is doing too, for you to fully understand what's
going on. You see, when using Java and HM.invokeWithArguments(),
conversions (varargs included) are taking place at two levels. The 1st
conversion
Dear Peter:
thank you very much for your thorough and extensive analysis taking the
evolvement of Java into account!
You use the Java compiler and its behaviour (which adds syntax sugar to the
Java language and is
known to stick strictly to the Java language specification) for explanations
Hi Rony,
I think what you found is a discrepancy between handling of varargs
methods using reflection vs. method handle's .invokeWithArguments().
Reflection basically ignores the fact that some methods are varargs
methods. It treats them exactly the same as if they had an array
parameter
On 11.03.2018 20:22, Rony G. Flatscher wrote:
> Well, still trying to find out what the reason is, that core reflection's
> invoke behaves
> differently to MethodHandle's invokeWithArguments in one single case so far
> (using the method
> java.utli.Arrays.asList(...)).
>
> Here is a little Java
Well, still trying to find out what the reason is, that core reflection's
invoke behaves differently
to MethodHandle's invokeWithArguments in one single case so far (using the
method
java.utli.Arrays.asList(...)).
Here is a little Java program that excercises reflective access to
