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

[edward]

On 10/13/2019 3:14 PM, Brian Goetz wrote:
> 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.
>>
Thanks Brian. I will make my attempt to ship a module that makes it look 
like the pool selection is part of the API (as much as it can). If that 
fails I will create an alternate implementation based on existing one 
and maintain that. I really believe the decision to use common pool that 
every parallel streams execution competes for behind the scenes across 
the app is a good idea. It sure looks good when you call it but no one 
can know what is happening in some other part of a given application. 
Maybe some other thread is waiting for IO on most of the common pool 
threads. Everything would hang in some (seemingly) unrelated part of code.