Remember?
Once we got methods like limit() & skip() which took concrete long type value and people were struggling about the conditions where they don't have such concrete long values but their situation was conditional, means they needed some method which can take the predicate to decide on the number of elements to accept or skip.
So?
We got takeWhile() & dropWhile() methods which take predicate & the above constraint was resolved now.
Why am I saying this?
Till date we were having flatMap() only if we need to go from Stream of Stream of T to Stream of T.
OR
If we need to go from Stream of T to...ummm...may be to Stream of R or may be we need to move to Stream of T but after some calculations.
So what we were doing for this?
flatMap() ?
Naaaaaaa....we did use of map() or may be filter() also
OR
One wants to move from one to many i.e. you are getting a stream of T type elements & you want to process each element to generate more elements from each element received from the given stream.
So what we did earlier?
We used map() to generate the collection of those new elements, then we did flattening using flatMap(). Well it worked but it was also getting performance hit due to intermediate Streams.
Whats the solution now?
Use mapMulti(), as shown below in oneToMany()
I am not sure, but may be some people had issues due to intermediate streams being created by intermediate actions above, which can hit the performance badly if your stream is huge.
So, we got mapMulti() now in Java16, which as per my below way is quite efficient but check by your way also before you hit this road....
Note :- Feel free to comment any of your concern regarding the thoughts shared here.
Check the below code I wrote to guage the performance -
Once we got methods like limit() & skip() which took concrete long type value and people were struggling about the conditions where they don't have such concrete long values but their situation was conditional, means they needed some method which can take the predicate to decide on the number of elements to accept or skip.
So?
We got takeWhile() & dropWhile() methods which take predicate & the above constraint was resolved now.
Why am I saying this?
Till date we were having flatMap() only if we need to go from Stream of Stream of T to Stream of T.
OR
If we need to go from Stream of T to...ummm...may be to Stream of R or may be we need to move to Stream of T but after some calculations.
So what we were doing for this?
flatMap() ?
Naaaaaaa....we did use of map() or may be filter() also
OR
One wants to move from one to many i.e. you are getting a stream of T type elements & you want to process each element to generate more elements from each element received from the given stream.
So what we did earlier?
We used map() to generate the collection of those new elements, then we did flattening using flatMap(). Well it worked but it was also getting performance hit due to intermediate Streams.
Whats the solution now?
Use mapMulti(), as shown below in oneToMany()
I am not sure, but may be some people had issues due to intermediate streams being created by intermediate actions above, which can hit the performance badly if your stream is huge.
So, we got mapMulti() now in Java16, which as per my below way is quite efficient but check by your way also before you hit this road....
Note :- Feel free to comment any of your concern regarding the thoughts shared here.
Check the below code I wrote to guage the performance -
