<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-2022-jp">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
(Moving this to core-libs-dev)</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cay,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regarding 1, Characteristics was a part of the Gatherers-contract for a very long time, alas it didn't end up worth its cost. There's a longer discussion on the topic here:
<a href="https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/118138.html" id="OWAbb71e7cd-7294-7965-8783-bdd3d51ad5cf" class="OWAAutoLink">
https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/118138.html</a> (and I'm sure that there were more, but that's the one which comes to mind)</div>
<div id="Signature" class="elementToProof" style="color: inherit;">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regarding 2, I did have a prototype which had a Downstream in the Combiner, but created a new dimension of complexity which made it even harder for people to move from sequential to parallelizable. The door isn't closed on it, but I remain unconvinced it's
worth the surface area for performance reasons.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
As a bit of a side-note, it's worth knowing that in the reference stream implementation, it is not unusual that parallel-capable stages are executed as "islands" which means that short-circuiting signals cannot travel across those islands. Since parallel-capable
Gatherers can be fused to execute in the same "island" if we get to a place where "all" intermediate operations are parallel-capable Gatherers, there'd be a single end-to-end "island" and hence the ability to propagate the short-circuiting would be preserved
in all modes of execution. Also worth knowing that a `gather($B!D(B)` immediately followed by a `collect($B!D(B)` can also be fused to run together.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers,<br>
$B"e(B</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b><br>
</b></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>Viktor Klang</b></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Software Architect, Java Platform Group<br>
Oracle</div>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend" style="color: inherit;"></div>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg" dir="ltr" style="color: inherit;"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> jdk-dev <jdk-dev-retn@openjdk.org> on behalf of Cay Horstmann <cay.horstmann@gmail.com><br>
<b>Sent:</b> Friday, 4 October 2024 19:58<br>
<b>To:</b> jdk-dev@openjdk.org <jdk-dev@openjdk.org><br>
<b>Subject:</b> Re: New candidate JEP: 485: Stream Gatherers</span>
<div> </div>
</div>
<div style="font-size: 11pt;">Hi, I have some belated questions about the design choices in this API that I could not find addressed in the JEP.<br>
<br>
1. Why aren't characteristics used to express "greediness/short-circuiting" or "sequentialness/parallelizability"?<br>
<br>
I understand that for the former I use ofGreedy/of, or implement Gatherers.Integrator.Greedy/Gatherers.Integrator. And for the latter, I use ofSequential/of, or, if I implement the Gatherer interface, have the combiner return defaultCombiner() or not.<br>
<br>
But it seems a bit complex and less familiar than the characteristics mechanism that exists for spliterators, streams, and collectors.<br>
<br>
The original design document (<a href="https://cr.openjdk.org/~vklang/Gatherers.html" id="OWA3e19ecba-d29b-aa46-48e7-260a96fa5158" class="OWAAutoLink" data-auth="NotApplicable">https://cr.openjdk.org/~vklang/Gatherers.html</a>) used characteristics, so I wonder
what motivated the change.<br>
<br>
2. Why wasn't the combiner() designed to allow pushing of elements to the end of the first range's sink? Then distinctBy could be parallelized without buffering the elements. More generally, with some state fiddling one can then handle the elements around range
splits.<br>
<br>
As it is, I don't see how to parallelize such computations other than to buffer all elements.<br>
<br>
I looked at the project at <a href="https://github.com/jhspetersson/packrat" id="OWA4f8e881d-a5a6-0a39-e6e9-8044bc312cde" class="OWAAutoLink" data-auth="NotApplicable">
https://github.com/jhspetersson/packrat</a> that implements a number of gatherers. Only one uses a combiner, to join buffers until their contents can be pushed in the finisher.<br>
<br>
Cheers,<br>
<br>
Cay<br>
<br>
On 02/09/2024 19:55, Mark Reinhold wrote:<br>
> <a href="https://openjdk.org/jeps/485" id="OWA949e487b-5652-d192-2f13-e0996d30a0c6" class="OWAAutoLink" data-auth="NotApplicable">
https://openjdk.org/jeps/485</a><br>
><br>
> Summary: Enhance the Stream API to support custom intermediate<br>
> operations. This will allow stream pipelines to transform data in ways<br>
> that are not easily achievable with the existing built-in intermediate<br>
> operations.<br>
><br>
> - Mark<br>
<br>
--<br>
<br>
Cay S. Horstmann | <a href="https://horstmann.com" id="OWA89ebc621-fd87-960d-67e4-baac1076a034" class="OWAAutoLink" data-auth="NotApplicable">
https://horstmann.com</a><br>
<br>
</div>
</body>
</html>