On 11/26/12 14:23, Anthony Lai wrote:
> Hi Philippe,
>
> Thanks for the suggestion. This is definitely a useful feature to have.
>
> Experts,
>
> While I think this is a valuable suggestion, I am not sure we could fit this
> requirement into Java EE 7 time frame. We might need to defer this for the next
> release, post Java EE 7. What do you think?
>
Deferring is probably OK, because for JDK8, there will be a
(static) ForkJoinPool.commonPool() that anyone can submit to.
In which case nothing is needed for EE. The main reason for this is that
parallel versions of the JDK8 lambda-ized collection stuff
need it. As in myCollection.parallel().filter(pred).map(m).reduce(r);
So, basically, anyone can indirectly submit to it. And give that,
there's no sense in not being upfront and adding commonPool method.
The underlying strategy is (or will soon be) to have the caller
of such methods take part in the parallel computation, so that
even if the internals that try to dynamically add worker threads
fail because of security mgr etc, the computation still succeeds
(although possibly much more slowly than it would sequentially.)
-Doug
> Regards
> Anthony
>
> On 11/25/12 7:19 AM, Philippe Marschall wrote:
>> Hi
>>
>> We would like to use fork/join in a Java EE container. I created
>> CONCURRENCY_EE_SPEC-20 [1] for this.
>>
>> [1] http://java.net/jira/browse/CONCURRENCY_EE_SPEC-20
>>
>> Cheers
>> Philippe
>