On May 5, 2009, at 12:25 PM, Fredrik Öhrström wrote: >> or invocation of private methods, see section 7.7 of the JVM spec. >> Rémi > > Thanks! A MethodHandle pointing to a private method makes sense. > Still the javadoc for findSpecial explicitly mentions the > constructor so > is there any reason for executing a constructor through a > MethodHandle?
Well, there is a strong reason for method invocation via invokespecial. To avoid burdensome workarounds, you need it if your dynamic language is going to extend Java classes. The topic was discussed on jvm-languages: http://groups.google.com/group/jvm-languages/browse_thread/thread/319982bfe1be9487/ That conversation is one of the reasons we have MethodHandles.findSpecial. The same points apply, slightly less forcefully, to invokspecial of constructors. One design goal with JSR 292 is to avoid forcing dynamic languages to generate bytecodes for at cut points: That's why method handles have method handles for private access, field access, and invokespecial (smalltalk sendsuper). The other goal, of course, is to make bytecode generation, when the implementor *chooses* to use it, to be much more profitable, because invokedynamic lets you punch through to the virtual metal. > Also, what is the reason for the specialCaller argument? (Also > referred > to as caller in the javadoc.) Since findSpecial creates a method handle which emulates an invokespecial instruction, we have to perform the access checks that pertain to that instruction. If a privileged module (like a language runtime) is calling findSpecial, we still want to make access checks for invokespecial against the logical caller of the invokespecial instruction, not against the runtime. (There may be another reason, which I'm not remembering... I'm a little sleep-deprived from the M3 push.) I suppose that reasoning applies to any lookup, not just findSpecial. The latest API factors the access checks more explicitly (into a "Lookup" capability object), so perhaps we can clean this up. Instead of calling MethodHandles.findVirtual, you call MethodHandles.lookup() (yielding a Lookup object, which is your factory) and then call lookup.findVirtual. The lookup guy authenticates the caller, and then can be used for several lookups from the same caller, or handed off from the caller to a trusted delegate (like a runtime). -- John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
