Round 2 feedback
paul.sandoz at oracle.com
Tue Feb 12 01:44:03 PST 2013
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
>> 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
> 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".
> 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.
More information about the lambda-dev