Stream.concat with varagrs

Olexandr Rotan rotanolexandr842 at gmail.com
Wed Sep 17 13:58:28 UTC 2025


Greetings to everyone on the list.

When working on some routine tasks recently, I have encountered a,
seemingly to me, strange decision in design of Stream.concat method,
specifically the fact that it accepts exactly two streams. My concrete
example was something along the lines of

var studentIds = ...;
var teacherIds = ...;
var partnerIds = ...;

return Stream.concat(
    studentIds.stream(),
    teacherIds.stream(),
    partnerIds.stream() // oops, this one doesn't work
)

so I had to transform concat to a rather ugly
Stream.concat(
    studentIds.stream(),
    Stream.concat(
        teacherIds.stream(),
        partnerIds.stream()
    )
)

Later on I had to add 4th stream of a single element (Stream.of), and this
one became even more ugly

When I first wrote third argument to concat and saw that IDE highlights it
as error, I was very surprised. This design seems inconsistent not only
with the whole java stdlib, but even with Stream.of static method of the
same class. Is there any particular reason why concat takes exactly to
arguments?

I would say that, even if just in a form of sugar method that just does
reduce on array (varagrs) of streams, this would be a great quality of life
improvement, but I'm sure there also may be some room for performance
improvement.

Of course, there are workarounds like Stream.of + flatmap, but:

1. It gets messy when trying to concat streams of literal elements set
(Stream.of) and streams of collections or arrays
2. It certainly has significant performance overhead
3. It still doesn't explain absence of varagrs overload of concat

So, once again, is there any particular reason to restrict arguments list
to exactly two streams? If not, I would be happy to contribute
Stream.concat(Stream... streams) overload.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250917/4377c66b/attachment-0001.htm>


More information about the core-libs-dev mailing list