Java 8 in a JEE Environment

[Brian Goetz]

I agree that it sure would be nice if you could get everything you want. 
  More inline.

>> For example, consider the following code:
>>
>>    list.parallelStream().forEach(e -> e.remoteEjbInvocation());
>>
>> What are your expectations about what should happen here?
>
> That I can access Java EE resources without any problem.

Would be nice.

>> Do you expect security and transaction context to be propagated to the pool thread?
>
> Yes.

Would be nice.

>> What tradeoffs are you willing to tolerate to enable this to work?
>
> I expect it to be a lot slower than in Java SE itself.

Are you willing for it to be 10x *slower* than the equivalent sequential 
code?  (Are you under the impression that there's some reason the 
parallel code can't be slower than the equivalent sequential code?)

>> Are you willing to impose a 100x parallelism hit to make this work?
>
> If that is the best the container can give me, yes. Then I will think
> before I use parallelStream() if the code is in my control. It has to
> at least *work*.

The emphasized use of *work* -- as if there were only one definition of 
"work" and that one is so obvious that you have emphasize it in this way 
-- is really troubling here.  It suggests that you are completely 
unwilling to consider any compromise in the programming model, even to 
the extent that this may subject every other user to a potentially 
crippling performance penalty.

It sure would be nice if you could have everything you want, and it sure 
would be nice for parallelism to be simple and always give you a result 
that is at least as fast as sequential, but that's not reality.

>> Are you willing to impose that hit on *every* parallel use case, even those that just want
>> to add up some numbers, not just those that actually need access to the
>> application context?
>
> If there is no easy way out, yes.

Too bad they don't get a vote.

>> What about the security and isolation implications?
>
> Each module should have its own pool instance, configurable for now
> using container-specific features. In the future, these can be
> standardized (maybe as early as EE 8, maybe only in 9).

This is technically naive.  Not only is this impractical with more than 
a few tens of apps running in a container, but even at numbers much 
lower than that, if any of them intend to use parallelism at all, having 
so many threads competing for the CPUs undermines everyone's parallelism.

>> Is it fair to subtly encourage ill-behaved clients to lock up the FJ pool
>> threads with long-running tasks like IO, even though this is clearly far
>> outside the design center of FJ?
>
> That is what people will use it for, especially for database operations.

This is a great argument for "just turn it off"!  This framework was 
designed and optimized for CPU-intensive data-parallel operations; you 
want to use it for something that is the exact opposite of that, and 
along the way are willing to impose crushing performance penalties on 
those that *are* using it as intended.

> In Java EE applications, users' expectations would be that parallelism
> should help mainly with batch operations in general or with a handful
> of small operations done sequentially today just because there is no
> easy way to run them in parallel.

Then JSR-238 should define a mechanism for this -- which is a different 
problem (and likely requires a different solution).  I get that the 
Stream API seems like a pretty way to express it so you want to just use 
that, but the underlying implementation (and no small part of the API 
design) is built around the needs of data-parallel operations, not 
IO-parallel ones.