Returning an IEnumerator should be sufficient to communicate that you only get to enumerate the thing once, and tacking a '.GetEnumerator()' on the end of things requires barely more typing than tacking '.ToList()' on the end.īy contrast, with streams, I feel like the Java maintainers gave me an API that's less powerful than the standard I'm used to on other platforms, on the grounds that they think I'm not a smart enough developer to handle a more powerful API. In the cases where a source can't be restarted, it's always seemed easy enough to me to just build up your LINQ query and then pass its enumerator back rather than the original enumerable.

Oftentimes you want to just pass along a lazy projection of that data, on the grounds that re-running the operation is less expensive than allocating a bunch more memory in order to cache the result to a list. When you're working with external data, yes, they can be expensive.īut most of what I've seen LINQ to Objects used for is simply mapping over data that already lives in memory.

Separate from that, as scarface74 mentioned, part of the point of LINQ is that the structure of the expression tree can be applied elsewhere, for example, to an SQL statement. If (p.getCategory() = 2 || p.getCategory() = 5 & isProductUnderDiscount(p)) filter(p -> p.getCategory() = 2 || p.getCategory() = 5 & isProductUnderDiscount(p))Įven in old style java6 syntax it's short, sweet, and to the point (as short as this library can let you write it): You can do the snippet with bog standard Java8+ stream API like so: Passing in an array is weird, so lets assume we're not working with really outdated codebases and a List is passed in instead.

A pet peeve of mine is how these libraries put the 'old' alternative in the worst possible light, creating the fake impression (at a casual glance) that the library makes your code much nicer.

Java linq equivalent