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,
