LINQ一直是.net程序系统中的一个非常棒的东东. Visual Studio 2008 已经引入了lambda 表达式和monads, 而同一时间Java6版本还在讨论要不要去掉泛型数据类型. 这一成果要归功于荷兰计算机科学家Erik Meijer, 他已经全停止掉别的项目.

Java的现状?

即将要发布的Java8和JSR-355,我们还需要LINQ?在过去的十几年中人们一直在尝试用LINQ给Java带来性能的改良。当时,Quaere和Lambdaj似乎在研究一种很有前途的库（非语言级别）. 事实上,StackOverflow上有很多Java的使用者提出的有没有与LINQ等价的Java做法(到现在依然) :

LINQ的Java实现?
LINQ的Java工具
Java中有跟LINQ类似的东西么?
Java等效LINQ和实体框架是什么?
有趣的是, "LINQ"已经发展到EL 3.0版本了!

我们真的需要LINQ么?

LINQ的高级特性存在重大缺陷, 从我们角度看来, 将会导致 "next big impedance mismatch". LINQ来源于SQL,这不是一件完美的事情. LINQ流行的LINQ-to-Objects,在.NET下是一种很好的查询方式.Haskell或Scala的成功已表明,真正的函数式编程可以忽略SELECT,WHERE,GROUP BY, 或者HAVING等来进行集合查询。他们使用"fold", "map", "flatMap", "reduce",来获得更高的性能.另一方面LINQ用 "skip", "take"使用混合式GROUP BY(不是OFFSET和FETCH).

事实上, 没有一种函数式查询方法可以超越那老旧但好用的SQL外部链接, 分组设置,或 框架窗口功能. 这些结构仅仅是一个SQL开发人员希望看到的结果的声明。他们不是自足的功能，这实际上包含在任何给定的情况下被执行的逻辑。此外，窗口功能，可以只用在SELECT和ORDER BY子句，这是一种明显声明方式，但是如果你没有SQL上下文这也是非常奇怪的。具体来说，SELECT子句中的窗口函数采用正确的数据预取影响整个执行计划和索引的方式。

相反，函数式编程可以在内存中就做到SQL的这些功能。使用SQLesque API 进行集合查询是用函数式方式狡猾的欺骗 了"传统"的人。这样的实现方式是不能将集合数据与SQL表查询的数据合并在一起的，也不会产生预期的SQL查询结果。

我该如何做?

相当简单，你如果使用SQL，你就有两个基本选择：

自上而下,专注你的Java模型. 使用Hibernate / JPA查询并且使用Java8 Streams API 转化Hibernate的查询结果.
自下而上,专注你的SQL关系模型. 继续使用JDBC或者jOOQ, 使用Java8 Streams API 转化的查询结果.
（译注:这老外不就是说Java8提供了一种接口么,这么费劲）

不能回头.拥抱未来!

虽然 .NET "领先" Java了一些，但这并不是LINQ的问题. 这主要是由于引入了lambda表达式并且支持lambdas的很多APIs. LINQ仅仅只是如何构建这样API的例子.

但我更加兴奋的期望Java 8中的 new Streams API, 以及它给Java生态系统带来的函数式编程. 这是一个由Informatech illustrates写的很棒的一篇博文:如何将常见的LINQ表达式转换为Java 8 Streams API表达式.

所以，不能回头.你可以不用再对.NET开发者眼馋嫉妒. 因为Java 8,我们已经不需要LINQ或者其他API模仿LINQ的"unified querying", 有一个更好的称呼，像"query target impedance mismatch".我们需要真正的SQL关系型数据库查询,我们需要Java 8 Streams API函数式编程查询内存集合数据. 给力 Java 8!