Grzegorz Piwowarek

Sure, I will gladly add clarification to remove the ambiguity, thanks!

Thanks, that's a nice idea! It's short and nice but it won't propagate exceptions properly and will cause the thread to get blocked forever waiting for LinkedBlockingQueue::take to return a result

Also, not all CompletableFutures are waiting for a thread, that's only if you create it with one of the async() factory methods. It is perfectly possible to create 100.000s of CompletableFutures without a single thread.

Yes, I used this approach myself in the library mentioned in the article - it's perfectly possible, but still most cases will involve them getting completed by some background threads. Waiting for the Project Loom to change it

JdbcTemplate serves the purpose really well, though

Oh, that's a very good point - will fix :)

It's deliberate - the empty case is not supported and rejected before even gets to the spliterator. There's no need to create the object if we don't need it at all. If we don't use it to handle empty cases, then no need to check this as well in tryAdvance

groupingBy is way more expensive - if your use case can be solved using filter() only, definitely go for it

Thanks for the suggestion, David. One question, though - are you familiar with how the reduce operation works on sequences? the article was supposed to be a high-level overview of groupingBy capabilities, that would be probably an overkill to explain the semantics of each operation not in the context of groupingBy usages

If I got you right, you don't need groupingBy() for this, you can simply use partitioningBy():

Map<Boolean, List<String>> result = Stream.of("abc", "def")
.collect(Collectors.partitioningBy(s -> s.startsWith("a")));

System.out.println(result); // {false=[def], true=[abc]}

I've been wondering the same, even dedicated a section to it here:

https://4comprehension.com/java-8-the-bad-parts/

In such case, I'd advise being explicit about the optionality of the result by returning an Optional instance, but it's a good point and I will it to the article, thanks :) I like the idea with freeing the supplier as well!

Martin, I'm not sure if I fully understand - can you elaborate, please?

It does not matter to what it compiles at this point. Provided functional interfaces miss the "throws Something" which simply does not compile if a checked exception is thrown inside

I just tried it - there are no shortcuts for .collect(Collectors.toXXX), unfortunately

The pragmatic reason for including the second solution is the fact that if that was omitted it'd immediately spark questions "Why not just sort the Stream instance?"

As long as API provides an iterator, it's fine to use Streams there - can't discuss with personal preference, though

Well, obviously we do not need to consume all elements at once. With Stream API, we can easily reach, let's say, first N elements + apply some processing on top of them - that's much handier than polling elements in a loop.

At the end of the day, you need to reach all accumulated elements to do something with them, right?

This is where it'd be nice to have something better than a for-loop

Good point - I will add some additional clarification there.

I will add also a Java 9 section in there.