Why one can't submit an alternative thread pool to the streams API?

[Brian Goetz]

No, I think you’ve got the wrong idea.  

It’s not that here is no agreement.  The experts agreed that 99.999% of the time, the absolutely right thing to do is use the common pool.  So that’s what the API supports.  There wasn’t agreement about what do do in the corner case of a corner case where the common pool isn’t right, so we did nothing there.  

If you think you should be using a different pool, or that there is a “decision to make” about what to do, you are almost certainly wrong, and should stop worrying about it and just use the common pool and feel great about it!



Sent from my iPad

> On Oct 13, 2019, at 7:18 AM, edward <edo3311 at gmail.com> wrote:
> 
> On 10/12/2019 7:03 PM, Brian Goetz wrote:
>>> It certainly isn't elegant. Perhaps a better way might be an argument to the parallel method that specifies the pool to be used?
>> This was discussed early during the development of the streams API, and quickly went into the bucket labeled “obvious but wrong.”  (It’s in good company.)  For every case where this is the right move, there are 10,000 others where it will be an attractive nuisance, but wrong.  It wouldn’t be fair to Java developers to dangle this option in their face.
>> 
>> Further, while everyone agrees the real estate between `.parallel(` and `)` is the right place to “build” to provide more control over parallel execution, no one agrees what we should actually build there.  Pretty convinced that a FJP is the wrong thing to build there, but still not sure what the right thing is, so we leave it undeveloped for now.
> 
> Thanks for the explanation. Ok, no one agrees on how to do it, yet it is done using ForkJoinPool with no API option to change that. If no one agrees it should be left for each and everyone to decide. Now, someone decided on FJP.
>