cs at schulte.it
Tue Aug 9 16:37:23 UTC 2016
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. 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