Java 8 in a JEE Environment

[Brian Goetz]

> I have suggested something along these lines before:
>
> http://markmail.org/message/rgmfphvk32gz6p6u#query:+page:1+mid:3e2zqh32ogrbdzjr+state:results
>
> 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
> cases."
>
> 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.