Translation Using asSam() and LINQ for Java
mingyeeiu+lambda at gmail.com
Sat May 29 00:25:29 PDT 2010
Sure. It's not clear exactly what people will want to do with closures
once JDK7 is released. Creating a variant of LINQ in Java using
closures and heavy bytecode analysis is, perhaps, not something that
people want to do.
But I just wanted people to know that if they do go the asSam() route,
then this avenue is likely closed. Then, they can more properly
evaluate the trade-offs of their particular closure implementation.
On Fri, May 28, 2010 at 9:46 PM, Neal Gafter <neal at gafter.com> wrote:
> It is true that project lambda doesn't appear to be offering the primitives
> that would be required to get LINQ-like behavior in Java, but I don't
> believe classloader hacking is the right way to do it.
> On Fri, May 28, 2010 at 12:26 PM, Ming-Yee Iu <mingyeeiu+lambda at gmail.com>
>> I'm concerned that translating lambda expressions to bytecode using
>> MethodHandles and asSam() will make it difficult if not impossible to
>> create some sort of LINQ-equivalent for Java.
>> If lambda expressions are compiled down to inner-classes, then someone
>> could add LINQ functionality to JDK7 using a clever classloader (as
>> long as there is automatic closure conversion to interfaces or support
>> for annotations on lambda expressions). When using MethodHandles and
>> asSam(), my gut feeling is that it is not possible to implement
>> something like LINQ without having a special compiler for a
>> LINQ-supporting-variant of Java.
>> Perhaps JDK7 could use only inner classes for its anonymous functions,
>> and this asSam() stuff could be delayed until JDK8 when people have
>> more experience with what they want to do with lambda expressions.
More information about the lambda-dev