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. Regards, -- Christian
