Fredrik Öhrström a écrit : > where adapter code is generated by calling for example > MethodHandles.appendArgument(). I am not entirely comfortable with this > construction. Mostly because JRockit does not have an interpreter. > > So, following a recommendation from John, that I should blog about > jsr292. :-) > Here is the link: > http://blogs.oracle.com/ohrstrom > > The post contains two independent proposals. Though the first (syntax) > proposal makes it > easier to reason about the second (method handle invocation) proposal. > > Thanks for reading! > > //Fredrik > Hi Frederik,
minor comments: - <int> is at the wrong place. *java example:* java.dyn.InvokeDynamic.<int>dosomething(123); - C++ pointer to member function No, more C pointer. Even if bound method handle are C++ pointer to member function. About boxing all primitive types to Object and considering Object as a generic container. It's really like how the DLR (microsoft) works. With the current state of the JSR292 you can as a language developer if you want already do exactly the same. And for language like Ruby, I think it could be a nice approximation because as you said it will reduce lot of boiler plate codes. But I think, the choice must stay in the hands of the language developer. Currently the hotspot prototype doesn't internally deals with all possible method types, byte, short, char are converted to int, double are converted to long, object are erased to Object, etc You can take a look to: http://hg.openjdk.java.net/jdk7/tl/jdk/file/tip/src/share/classes/sun/dyn/MethodTypeImpl.java So I think that what you have described here, is not a new JSR292 spec but more how JRockit can implement the JSR292. If the JRockit implementation want to box primitive type, no problem :) The class AppendIntArgument, a class that can do what it wants and is a MethodHandle already exists in the prototype, It uses JavaMethodHandle as base class. You can take a look to the fidget demo from john, the last mail of http://groups.google.com/group/jvm-languages/browse_thread/thread/47b4423aa99be008 Particularly, the inner class Guard. I agree with you that it could avoid to implement lot of static methods in MethodHandles. Anyway, some of them like convert, spread/collect, bind are very common and I think it's a good idea to provide them even if they are written internally as subclass of one adapter class. On javac support: your javac support is close to a closure proposal :) I think we can output a spec without a complete (typecked) support of MethodHandles in Java to avoid the closure trap :) Moreover, I has already said I'am for two new LDC versions that allow to perform lookup on method handles and on method types. But I don't think it mustbe the only way to get direct method handles. JRockit alreday implement java.lang.reflect, It doesn't seem more difficult to implement findVirtual, findStatic, etc. Rémi PS: sorry for the broken english _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
