I would like to discuss the MethodHandles factory

[Rémi Forax]

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