No way to create a no-op MethodHandle that returns void?
Rémi Forax
forax at univ-mlv.fr
Tue Jan 24 01:18:42 PST 2012
On 01/24/2012 09:40 AM, John Rose wrote:
> On Jan 23, 2012, at 11:26 PM, Charles Oliver Nutter wrote:
>
>> Oh, that does seem to work...what an ugly hack. And actually, you can
>> just use Object.class but cast the resulting return to void, and it
>> works.
>>
>> So basically, I do this:
>>
>> handler = MethodHandles.constant(Object.class, null)
>> handler = MethodHandles.asType(void.class)
> The EG considered things like having MethodHandles.constant(void.class, null) or identity(void.class).
> Even identity(methodType(void.class, Throwable.class, String.class)).
> There is a certain logic to such things but it didn't feel regular enough, and users can get the same effect by asType (as you realized).
>
> Noctarius is right in referring to Void. The MH API treats Void fairly regularly as the wrapper type for void, with a unique (unit) wrapped value of null.
>
>> handler = MethodHandles.dropArguments(0, Throwable.class, String.class)
>>
>> And then use that as the exception handler.
>>
>> It's not exactly the no-op I wanted, since it has the cast logic in
>> there, but it's close enough.
>>
>> FWIW, I'm using this in the tests for invokebinder, for testing the
>> tryFinally operation:
> That binder stuff is great. Next, we want a builder syntax in Java (for more than just List+Map constants). Plus a little type-system bridge from Foo::bar and foo->bar to MethodHandle. Then we can compose our method handles quite swimmingly.
Lambda should provide bridge from Foo::bar to MethodHandle :)
>
> -- John
Rémi
More information about the mlvm-dev
mailing list