david.holmes at oracle.com
Tue Aug 9 23:26:54 UTC 2016
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.
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.
More information about the core-libs-dev