Java 8 in a JEE Environment
brian.goetz at oracle.com
Tue Apr 16 08:03:11 PDT 2013
> I have suggested something along these lines before:
> The most relevant part of Brian's response was:
> "We're working with the EE folks to figure out what our options are.
> The right answer may well be to fall back to sequential in some
> I still think not providing first class support for Java EE is going
> to cause a lot of damage in the wild.
The hard part -- and this has been the subject of much discussion with
the EE team -- is what exactly *does* first-class support for Java EE
mean in this context?
For example, consider the following code:
list.parallelStream().forEach(e -> e.remoteEjbInvocation());
What are your expectations about what should happen here? Do you expect
security and transaction context to be propagated to the pool thread?
What tradeoffs are you willing to tolerate to enable this to work? Are
you willing to impose a 100x parallelism hit to make this work? 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? What about the security and
isolation implications? 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?
The bottom line is that it's really easy to stand up and say "it should
do the right thing", but it is far from obvious what the right thing is,
and how much we should be willing to punish use case A in order to
enable use case B. (If the right thing were obvious and free, it would
have already been done.)
EE containers have long used the standard trick of intercepting access
to thread pools, and setting up context before the user code executes in
it. That works great for millisecond-scale tasks like web page hits.
That falls apart completely for nanosecond-scale tasks (because the
setup cost effectively folds into the serial fraction of Amdahl's Law).
So trying to apply the usual thread-pool tricks to fork-join pools
virtually guarantees it would be better to just turn parallelism off
entirely -- which is not the outcome anyone wants.
More information about the lambda-dev