Paul,
A call to the following:
Object o = rmh.invokeExact((MethodHandle) null, new Object[]{});
Will result in a:
java.lang.UnsupportedOperationException: cannot reflectively invoke
MethodHandle
However, the stack trace corresponds to the stack where the call to "unreflect"
was performed and not where the invocation occurs.
The reason is that the preconstructed exception is thrown and not
created on every invocation:
mh = mh.bindTo(new UnsupportedOperationException("cannot reflectively
invoke MethodHandle"));
Further it does "mh.withInternalMemberName(method, false)", that i cannot
explain. Why do we need to re-associate the MH throwing the USO with the member name
corresponding to the MH.invokeExact/invoke method?
I think the main reason is to keep direct method handle cracking API
(MethodHandles.revealDirect()) working for MethodHandle.invoke*.
Actual method handle structure in this case is more complex than a
simple DMH, so additional trick with WrappedMember is needed to preserve
an illusion an ordinary direct method handle is returned.
For such edge cases perhaps caching is not required.
Agree, caching shouldn't be important for such cases.
Best regards,
Vladimir Ivanov
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
