Javac syntax for MethodHandle (Was Re: I would like to discuss the MethodHandles factory)

[Fredrik Öhrström]

Rémi Forax skrev:
> 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 :)
>   
All the runtime access methods like findVirtual, findSpecial and
findStatic should of course remain. :-) I am only talking about that
I would really like to be able to refer to javac compile time checked
method handles (and potentially method types as well). I believe it to be
very useful since in many situations you will create a method handle
and know at compile time what method you want handled. For
example you might want to return a method handle to one of
your own methods. Catching a spelling mistake at compile time is
very useful.

I picked a syntax inspired by the javac support for invokedynamic return 
type modifier
as proposed by John. However I did move <int> close to the parentheses 
because you
can then visually separate the MethodType.

#MyClass.calculate<int>(int,int)

can be separated visually into two groups:

#MyClass.calculate         <int>(int,int)

Where #<int>(int,int) would be a valid MethodType.

By allowing javac to look for a match in your class or in your
imported classes, even if you have not specified all the details
of the method handle, the source code will be very concise.
For example, all of these refer to the same MethodHandle:

#clone #Object.clone #java.lang.Object.clone 
#java.lang.Object.clone<java.lang.Object>()

and would be enough for the compiler to generate:

ldc java/lang/Object.clone()Ljava/lang/Object;

And finally, to automatically bind the method handle would
also be very useful. I can imagine a lot of uses for:

return #this.notifyMe;

which would compile into:

aload 0
ldc app/Application.notifyMe()V
invokestatic MethodHandles.bind(Object,MethodHandle)MethodHandle
areturn

(You can of course replace "this" with any non-primitive variable.)

The # symbol was chosen because all the characters on a US-keyboard
are put to use in Java code. Except # and @ that are used
only for javadoc and annotations. It seems like every new syntax proposal
for Java want to use #. :-)

//Fredrik