Sweet, that kicks ass :) On 3 June 2010 12:10, Reinier Zwitserloot <[email protected]> wrote:
> 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- "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.
