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. -- John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
