Executors enhancement

[David Holmes]

On 10/08/2016 2:37 AM, Christian Schulte wrote:
> Am 08/08/16 um 02:04 schrieb Brian Goetz:
>> If a library wants to offer a customization point where it accepts an
>> FJPool, clients should be encouraged to pass the common pool (and the
>> common pool is a good default) unless there are specific reasons not to.
>
> Exposing parallelization at API level is what I want to avoid. I
> consider parallelization an implementation detail. Nothing to be exposed
> at API level.

Transparent parallelization is like transparent distribution - might 
sound nice but in practice is unrealistic. This is why you have to 
opt-in to parallelization in the Stream framework. Other libraries also 
need to expose some hook to opt-in and allow configuration of 
parallelisation. That doesn't have to be exposed in the primary API but 
should be exposed through some kind of configuration API. The idea that 
parallelization is just an implementation detail is only considering the 
functional aspect in my opinion.

David
-----

  In my opinion this is not about library context. Not even
> application context. Having such common executor really is platform
> context. I thought about re-designing libraries to make use of
> 'java.beans.beancontext' just to be able to access some kind of services
> internally. There is no way to re-design the APIs just because the
> implementation wants to employ parallelization and needs a common pool.
> So I am glad something like that is provided in Java 8.
>
> Regards,
>