Additional method on Stream

Stephen Colebourne scolebourne at
Tue Apr 28 09:18:06 UTC 2015

On 27 April 2015 at 16:23, Paul Sandoz <paul.sandoz at> wrote:
> One issue is there are zillions of possible more specific convenience operations we could add. Everyone has their own favourite. Some static methods were recently added to Stream and Optional in preference to such operations.
> There has to be a really good reason to add new operations. I realize this use-case might be more common than others but i am still yet to be convinced that it has sufficient weight given flatMap + lambda + static method.
>> BTW, I wait months before making this request to see if it really was
>> common enough a pattern, but I'm confident that it is now.
> Were you aware of the pattern using flatMap during those months?

No, but if I had, I would not have used it. Its a rubbish workaround.
It creates extra objects for no value. It involves statically
importing another random utility. and it is less expressive - the
desire is to filter by type, so I want the filter method.

I do understand the desire to control methods, but API design isn't
just about minimalism, it is also about meeting common use cases in a
natural way. The parallel is of course a standard if (obj instanceof
Foo) statement in Java, where developers often curse that they have to
additionally cast obj after the check. Why can't the compiler just do
it? (Kotlin does for example). While changing the Java language to do
this is hard, changing the Stream API would be easy, and good value
given a year's coding with streams.


More information about the core-libs-dev mailing list