Translation Using asSam() and LINQ for Java

[Ming-Yee Iu]

> I think that implementing LINQ with bytecode analysis is the wrong
> approach, for two reasons:
>
> - One the most important features of LINQ is the integration in the
> host language's syntax. Without that, you don't have a query DSL
> anymore, just a clever API. To have that feature, compile-time support
> is needed, and once you modify the compiler, there's no reason to do
> bytecode analysis anymore.

Again, I will reiterate that I am not trying to convince people about
the benefits of LINQ, database queries in Java, or of metaprogramming
in Java--those are different debates. Feedback was requested on
different translation proposals. My feedback is that a translation
scheme that involves doing things at runtime with magic, opaque
objects may save on static footprint, but there are additional
trade-offs that should be considered, including

a) doing things at runtime makes static analysis of bytecode harder.
You cannot determine who implements a certain interface with a quick
scan of the class hierarchy, for example

b) opaque, runtime-generated wrapper objects can hide useful runtime
information. For example, some functional frameworks will cache the
result of a computation and reuse it if they asked to do processing
with the same function. Opaque wrapper objects hide this sort of
information. (I understand that theoretically, a framework should not
try to peek into the functions that are passed to it, but in reality,
things like the instanceof operator still get a lot of use in Java.)

> - If closures will be added to the Java language specification, only
> their syntax and semantics will be specified - not their
> implementation. So basing bytecode analysis on the fact that the Sun
> JVM will implement closures a certain way will likely make "LINQ" work
> only on JVMs that implement closures the same way as Sun. You cannot
> forbid other implementations to use asSam().

This sort of stuff already happens a lot in J2EE and elsewhere.