Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Paul Sandoz paul.sandoz at
Tue Aug 18 16:49:07 UTC 2020

Hi Patrick,

This looks good. To resolve the ambiguity of when results are undefined I suggest we tweak the docs at the various locations, see below. No need for another round of review.

I can understand the desire to place the primitive functional interfaces in j.u.functions, but for reasons previously stated they are fine in the current location.


      * accepts replacing elements. The mapping function operates on the consumer,
      * zero or more times, for acceptance of replacing elements.
-     * <p>The results of this method are undefined if the {@link Consumer}
-     * argument is called outside the scope of the mapper function.
-     *
      * <p>This is an <a href="package-summary.html#StreamOps">intermediate
      * operation</a>.
+     * The results of this intermediate operation are undefined if the
+     * {@code consumer} argument is operated on outside the scope of
+     * its application to the mapping function.
      * @implSpec
      * The default implementation accumulates accepted elements into an internal

> On Aug 11, 2020, at 11:11 AM, Patrick Concannon <patrick.concannon at> wrote:
> Hi,
> Please find the next iteration of mapMulti in the new webrev below. 
> In this iteration the following changes have been made:
> The API note for mapMulti has been updated.
> Sub-interfaces for {Int, Double, Long}Stream have been refactored to be more specific to mapMulti.
> The examples have been changed, and now include a reference to how an explicit type parameter can be used in conjunction with mapMulti.
> The CSR and specdiff have also been updated to reflect these changes.
> webrev:
> specdiff:
> CSR:
> Kind regards,
> Patrick

More information about the core-libs-dev mailing list