[topspin]

> [streams are] pretty crappy compared to Linq

I think that's unfair to the Streams API. It wasn't intended to solve the same problem as Linq and the problem it does solve it does very well. Streams transform collections. Streams API statements are usually elegant and the party piece of Streams is concurrency with parallelStream(), which will distribute stream operations across threads safely and transparently.

Perhaps java should have a Linq equivalent, but the fact that the Streams API isn't that isn't actually a knock on Streams. In the meantime there is JOOQ and others that deliver elegant query syntax with compile time type safety.

[skwirl]

This sounds like a pretty serious misunderstanding of what LINQ is. LINQ is a general query capability of which there are multiple providers - one of them is for SQL, which may be what you are thinking LINQ is, but another is for in-memory enumerables ("LINQ to Objects"). LINQ to Objects and Java Streams actually are intended to solve the exact same problem.

If you think Streams API statements are elegant compared to LINQ, I again don't think you are familiar with LINQ. C# has language features Java does not have which usually makes LINQ much more succinct. For example, imagine a list of order items where each item has a double "Price" property. If you want to sum the price of all the items, here's how you'd do it in C# vs Java:

C#: double sum = items.Sum(item => item.Price);

Java: double sum = items.stream().mapToDouble(Item::getPrice).sum();

Java lacks extension methods, so stream() must first be called to get at any stream methods. Worse, Java has generic type erasure, so I have to to call "mapToDouble" to get this hacky concoction called a "DoubleStream" which actually has the sum method.

Not the end of the world, for sure, but definitely crappy compared to LINQ. There are lots of other irritating problems, such as Stream itself not being enumerable and the need for calling collect with a Collector.