Round 2 feedback

[Paul Sandoz]

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.

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.