The impact of Stream Gatherers on StreamConstraints

[ace19wre]

I have been poking around in the JDK preview and came across JEP 461: Stream Gatherers
From the proposal itself,
Stream::gather(Gatherer) is to intermediate operations what Stream::collect(Collector) is to terminal operations.

From the documentation of the solver :

Collecting elements into a Collection negates benefits of incremental score calculation, as all operations on the resulting Collection will no longer be incremental. If performance is a concern, avoid these collectors.

But with few examples that I have seen so far the collectors are used as an intermidate step and not a terminal step( which I assume impacts the performance and hence should be avoided?), has there been any internal testing with Stream::gather(Gatherer) and are they viable to maintain Incremental Score Calculation Performance?

[triceo]

Hello @ace19wre, and a good question!

Java's streams do not have any requirements for incrementality, or for repeatability. Once a Java stream is terminated, you can never run it again. And every element only flows through it once. Java streams also don't have a concept of tuple cardinality (uni, bi, ...).

For those reasons, the similarity between Java streams and Constraint Streams is only superficial - both are fluent APIs which allow for a less imperative approach to data processing, but many of their concepts aren't mutually transferrable. Constraint Streams share no implementation with Java streams, they are completely independent systems.

When it comes to Gatherers specifically, you could argue Constraint Streams API already has a functionality like that. It's called a Constraint Collector, used with a groupBy building block. By implementing a custom Constraint Collector, you can accomplish pretty much any transformation.

The problem of losing incrementality in Constraint Streams comes from collecting data into a Collection - because collections require iteration, and iteration has a complexity of O(n), whereas in Constraint Streams we generally strive for O(1).