Round 2 feedback

[Paul Sandoz]

On Feb 12, 2013, at 10:39 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> On Feb 10, 2013, at 1:13 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> - Here is my greatest concern so far: parallel streams in their current
>>> form will cause Java EE applications to fail miserably. In such
>>> environments, threads cannot be freely created and all types of leaks and
>>> exceptions can happen if one calls a method in a non-container managed
>>> thread. Since calling parallelStream is cheap, I guess people will do it
>>> often and it will be hard for Java EE developers to find out if any
>>> third-party Java SE 8 code is safe to call or not - and enterprise
>>> developers unaware of such restrictions, which are unfortunately the
>>> majority, will be puzzled by never seen exceptions or erratic behaviour in
>>> production. My suggestion would be to add a parameter to parallelStream and
>>> parallel which is an abstraction to thread management,  forcing people to
>>> think about it. Then one can construct a wrapper over the
>>> container-specific API for now and Java EE 8 can provide the standardized
>>> one;
>> 
>> yes, the issue is even more complex than that when people will start to 
>> use parallelStream() inside library codes because the library will work 
>> in Java SE and not with Java EE.
>> The real question seems to be how JEE container can support the common 
>> ForkJoinPool.
>> 
> 
> Currently the stream impl provides nothing special in this regard, if the current thread is an instance of ForkJoinWorkerThread the common pool will be used.

I meant to say " is *not* an instance of ForkJoinWorkerThread".

Paul.

> 
> So one obvious solution is for the thread of the web app to be an instance of ForkJoinWorkerThread that holds a ForkJoinPool for the web app, but i am not sure if that is really the right solution for EE.
> 
> Paul.
>