Round 2 feedback

[Michael Nascimento]

On Sun, Feb 10, 2013 at 10:13 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> Weird,
> this works for me:
>    import static java.util.stream.Collectors.*;
>
>    static class Functions {
>      static Function<Object, String> string() {
>        return Object::toString;
>      }
>    }
>
>    public static void main(String[] args) {
>      Arrays.stream(args).map(Functions.string()).collect(toList());
>    }
>

NetBeans to blame, sorry for that.

>> - 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.

I guess if Java EE containers were willing to support threads created
somewhere else, they would have done it long ago and we wouldn't be
getting JSR-236 in Java EE 7 instead:

http://jcp.org/en/jsr/detail?id=236

Regards,
Michael