Java 8 in a JEE Environment (original) (raw)

Brian Goetz brian.goetz at oracle.com
Tue Apr 16 10:21:57 PDT 2013

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.

More information about the lambda-dev mailing list