java8 linq4j
这篇文章最初发表在jooq.org上 ，这是一个从 jOOQ 开发人员的角度关注Java的博客 。
长期以来， LINQ是.NET软件工程生态系统中发生的最好的事情之一。
通过在Visual Studio 2008中引入lambda表达式和monad ，它使C＃语言跃居Java之前，Java在当时是版本6，但仍在讨论泛型类型擦除的优缺点。
这项成就主要归功于荷兰计算机科学家兼染料专家Erik Meijer并获得其认可，他现在正从事其他项目 。
Java现在在哪里？
随着即将发布的Java 8和JSR-355 ，我们仍然需要LINQ吗？ 自上个十年中期以来，已经进行了许多尝试来将LINQ的优点带给Java。 当时， Quaere和Lambdaj似乎是在图书馆级别（而不是语言级别）上有希望的实现。 实际上， 大量流行的Stack Overflow问题暗示了有多少Java人士（现在仍然是！）实际上正在寻找等同的东西： 有趣的是，“ LINQ”甚至已经成为EL 3.0 ！但是我们真的需要LINQ吗？
LINQ有一个主要缺陷，该缺陷被宣传为一项功能，但在我们看来，这将不可避免地导致“下一个大阻抗失配” 。 LINQ受SQL启发，这根本不是一件好事。 LINQ最流行于LINQ-to-Objects ，这是查询.NET中集合的一种好方法。 但是， Haskell或Scala的成功表明，“集合查询”的真正功能本质倾向于使用除SELECT ， WHERE ， GROUP BY或HAVING之外的其他术语。
他们使用的术语包括“折叠”，“地图”，“ flatMap”，“ reduce”等等。
另一方面，LINQ使用GROUP BY和术语“ skip”，“ take”（而不是OFFSET和FETCH ）的混合体。
实际上，除了良好的旧SQL 分区外部联接， 分组集或框架窗口函数之外，没有什么比功能真理更重要的了。
这些构造仅仅是SQL开发人员希望看到的结果的声明。
它们不是独立的函数，实际上包含要在任何给定上下文中执行的逻辑。
而且，窗口函数只能在SELECT和ORDER BY子句中使用， 这在以声明方式进行思考时很明显 ，但是如果您没有SQL上下文，这也很奇怪。
具体来说， SELECT子句中的窗口函数会影响整个执行计划，以及采用索引来预取正确数据的方式。
相反，真正的函数式编程对内存中集合的作用比SQL还要多。
使用SQLesque API进行集合查询是一个狡猾的决定 ，目的是欺骗“传统”人员采用函数式编程。
但是，使集合和SQL表查询可以混淆的希望令人失望，因为这样的构造不会产生所需SQL执行计划 。
相反，真正的函数式编程对内存中集合的作用比SQL还要多。
使用SQLesque API进行集合查询只是错误的决定。
令人失望的是，收集和SQL表查询可能会混淆在一起，因为这样的构造将不可避免地产生可怕SQL执行计划 。
但是，如果我
这很简单。 当您执行SQL时，有两个基本选择。- “自上而下”进行操作，将大部分精力放在Java域模型上。 在这种情况下，请使用Hibernate / JPA通过Java 8 Streams API查询和转换Hibernate结果。
- “自下而上”进行操作，将大部分精力放在您SQL /关系域模型上。 在这种情况下，请使用JDBC或jOOQ，然后再次使用Java 8 Streams API转换结果。
拥抱未来！
虽然.NET在Java领域已经“领先”一段时间了，但这并不是由于LINQ本身引起的。 这主要是由于引入了lambda表达式以及lambda对* ALL * API的影响。 LINQ只是如何构造此类API的一个示例，尽管LINQ赢得了大多数赞誉。 但是，我对Java 8的新Streams API以及它将如何包含Java生态系统中的某些功能编程感到更加兴奋。 Informatech在一篇非常好的博客文章中说明了常见的LINQ表达式如何转换为Java 8 Streams API表达式。 所以，不要回头。 停止羡慕.NET开发人员。 使用Java 8，我们将不需要LINQ或任何试图以“统一查询”为基础来模仿LINQ的API，这对于真正的“查询目标阻抗不匹配”来说是一个更好的称呼。 我们需要真正SQL来进行关系数据库查询，并且需要Java 8 Streams API来进行内存中集合的功能转换。 而已。 使用Java 8！ — 通过Shutterstock 链接图片翻译自: https://jaxenter.com/does-java-8-still-need-linq-or-is-it-better-than-linq-108061.html
java8 linq4j