I would like to discuss the MethodHandles factory
forax at univ-mlv.fr
Mon May 11 08:38:07 PDT 2009
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:
> 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!
- <int> is at the wrong place.
- C++ pointer to member function
No, more C pointer. Even if bound method handle are C++ pointer to
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
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:
So I think that what you have described here, is not a new JSR292 spec
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
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
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.
PS: sorry for the broken english
More information about the mlvm-dev