lambda and dynamic JVM languages interropt

[Jochen Theodorou]

Am 06.11.2012 09:50, schrieb Remi Forax:[...]
> Thinking a bit about that, the current lambda metafactory API is not
> totally aligned with this goal.
> The current API offers only single entry point (two in fact with
> serialization) so there is no way for
> JVM language developers to choose which representation of lambdas is
> most suited for their language
> (dynamic generation of inner-classes or method handle proxy).
> I think we should provide 3 entry points (6 with serialization), the one
> Java uses which select the best implementation
> and delegates to one of the lambda implementation entrypoints, and 2 for
> the two ways to represent a lambda.

I am following the list only from time to time and I think there is a 
detail I am missing here. So afaik we generate for the lambda a method 
and we will have an invokedynamic based call site that is given the 
handle of that method as well as the "target". The conversion is then 
done by the metafactory API, which means either directly with 
MethodHandles or with an inner class, which is generated at runtime. I 
hope I am right so far.

Now you suggest that I can force one or the other way, instead of going 
though the generic path. My question now is... why should I not want the 
generic way and force one?

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org