Not quite. MethodHandles aren't referring to a java library feature; they are referring to a JVM feature. You can have an object-like construct on the stack or on the heap, just like any other object or primitive value, which represents a method invocation-to-be. This may feel a little bit like a java.lang.reflect.Method object, but it's different in a few ways:
1) It's a JVM-native concept. j.l.r.Method isn't; j.l.r.Method is a fairly ordinary class where a bunch of its methods, including for example 'invoke' are marked as 'native'. There's a difference; there is no class file for MethodHandle at all, and its spec is much more closely related to the core JVM C code itself, it's not just a sort of add-on C file like j.l.r.Method's invoke. 2) The security checks on accessibility are done at the time the method handle object is created. In other words, if code in A.class creates a method handle to a private method 'foo' in A.class, and then gives this method handle to B.class which then executes the method handle, that works. If you were using j.l.r.Method, that wouldn't, because j.l.r.Method does its security check on execute. You can of course make j.l.r.Method work via .setAccessible(true) magic, but that causes a call to the security manager. Note that the security model isn't affected; if I have access to a method already I can of course leak it to whomever I want, simply by wrapping a call to it into e.g. a Runnable and passing that runnable around. 3) MethodHandles come in a few flavours and have certain flexibilities (including the notion that MH's have a 'this' referent or not). For example, there's a JVM-native-ish operation to curry them. (currying = supplying some but not all parameters, effectively turning them into a new method that takes less parameters. For example, turning add(int, int) into add5(int) which always uses '5' as first argument. add5 is like a new handle with a different signature). Currying without JVM support is kinda annoying and somewhat pricey, as it would involve creating a new class, running up permgen, causing a class parse hit, etcetera. 4) MH's are designed primarily as a language-agnostic method handle vehicle; they do NOT reflect any particular need for the java language and are completely unrelated to the closures-for-java (a.k.a. project lambda) effort, though most likely project lambda will gladly use the MH feature. MH is being driven primarily by the alternative language crowd. 5) In general, MHs are designed with speed, speed, speed, speed, and low memory requirements in mind. Since java 1.4 j.l.r.Method isn't exactly a sloth either, but MHs should be faster still, and take considerably less permgen, which is a good thing. On Jun 2, 7:32 am, Josh McDonald <[email protected]> wrote: > Sweet, thanks for that info :) I didn't know about MethodHandle, I'm > assuming it's something like j.l.r.Method, but pre-bound to a specific > "this"? > > -Josh > > On 1 June 2010 21:28, Reinier Zwitserloot <[email protected]> wrote: > > > > > > > A clarifying comment by Maurizio on lambda-dev claims that they are > > currently implementing something that's similar to the straw man > > presented by Mark Reinhold at Devoxx '09, with some of the tough > > questions in it removed (such as using .() instead of plain parens to > > 'execute' a closure), so the widespread discussion on lambda-dev can > > at least experiment better. > > > In otherwords, 'making the compiler-writer's job easy' is apparently > > part of the plan, at least for now. > > > A standard function type in the JVM *already exists* in the jdk7 > > specs; it's called MethodHandle. There are already calls going out > > amongst the alternative languages on the JVM crowd to start switching > > to it. Also, partly motivated by the closures stuff, MethodHandle > > objects will most likely gain a JVM-based 'asSam()' method which means > > at least some of the structural typing that other languages offer can > > be done 'natively' instead of working by using a lot of reflection > > magic. So, Josh, Michael, time to lobby your friendly local > > alternative language developer to get on the bandwagon :) > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > Josh 'G-Funk' McDonald > - [email protected] > - http://twitter.com/sophistifunk > - http://flex.joshmcdonald.info/ -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
