RFR: 8319123: Implementation of JEP-461: Stream Gatherers (Preview) [v7]

Remi Forax forax at univ-mlv.fr
Tue Nov 14 14:55:44 UTC 2023



----- Original Message -----
> From: "Viktor Klang" <vklang at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Tuesday, November 14, 2023 11:32:48 AM
> Subject: Re: RFR: 8319123: Implementation of JEP-461: Stream Gatherers (Preview) [v7]

> On Tue, 14 Nov 2023 09:48:13 GMT, Rémi Forax <forax at openjdk.org> wrote:
> 
>> Hello, the relation between a stateless gatherer (default initializer) and the
>> default combiner are not obvious to me.
>> 
>> A default initializer means stateless and a default combiner means sequential,
>> so if i want the integrator of my stateless gatherer to be called in parallel,
>> i need to not use the default combiner but at the same time the combiner I will
>> pass as parameter will not be called because the gatherer is stateless ?
>> 
>> Having to create a combiner that will be not called seems weird. I'm sure i'm
>> missing something ?
> 
> It stems from the observation that the nature of something being stateless does
> not mean that it doesn't have restrictions on encounter order (see forEach and
> forEachOrdered as an example). 

yes,

> Parallelization means foregoing encounter-order
> (of execution -- not necessarily of output), so by requiring to specify a
> combiner to opt into parallel (unordered execution) means that the default is
> correct and safe under all evaluation modes, and opting into out-of-order
> execution is inspectable (in terms of ocular inspection of code).

I've no problem with intermediary operation having to opt-in to be parallel.

But I found the API surprising, the way to opt-in is to provide a combiner which does not work well with a stateless intermediary operation which by definition does not need a combiner.

Why not either using capabilities (like Spliterator and Collector) or subclasses like Greedy, or any other mechanisms instead of the concept of a default initializer/combiner ?

The idea of default initializer/combiner is that those are orthogonal, you can choose the default initializer and the default combiner separatly, but an initializer and a combiner are related, they work together so the idea of default initializer/combiner is leaky. A contrario, there is no such isseu with the default finisher because this one is independant of the others methods of a Gatherer.

Rémi

> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/16420#issuecomment-1809940566


More information about the core-libs-dev mailing list