Hello again!
For that compiler error which you could reproduce, will you file a bug report,
or is the API that much under change currently, that it's not relevant yet?
Sorry, the proposed workaround produces same error for me.
For the use case "calling a method whose signature is unknown prior to runtime"
(such as some lib, loaded externally) :
- Is invokeVarargs the only method which could "replace" the old slow
Method.invoke for the given use case?
- As mentioned in first mail, my benchmark showed for invokeVarargs
nearly same slowness as Method.invoke.
- So, the given use case doesn't profit from new concept at all?
In that case: :'(
Best regards,
Ivan G S
06.11.10, 20:28, "Rémi Forax" <fo...@univ-mlv.fr>:
> You've spot a bug:
> (int) methodHandle.invokeExact(); // error: not a statement
> should compile.
>
> The compiler should consider it as a statement, like it does
> for invokedynamic.
>
> If you use a dummy variable, it works:
>
> int foo;
> System.out.println("\n\nATTEMPT 1");
> foo = (int)InvokeDynamic.anything();
>
> System.out.println("\n\nATTEMPT 2");
> foo = (int)methodHandle.invokeExact(); // warning: unchecked
> generic array creation
>
> System.out.println("\n\nATTEMPT 3");
> foo = (int) methodHandle.invokeExact(); // error: not a statement
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
