On Mar 18, 2015, at 3:59 AM, Paul Sandoz wrote:
>
> Perhaps such method handles were originally cached to avoid an explosion
> (deliberate or otherwise) of class generation of LFs, but now there is more
> sophisticated LF caching in place this is not necessary.?
That's probably correct. Per-M
On Mar 17, 2015, at 8:24 PM, Vladimir Ivanov
wrote:
> 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
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 perfor
Hi,
I am wondering if people can help shed some light on the MHS.Lookup.unreflect
implementation for the MethodHandle.invoke/invokeExact.
It's clear that one should not be able to operate reflectively on polysig
methods and when doing do a USO is throw (as specified), but the implementation
se
