Java 8 in a JEE Environment
misterm at gmail.com
Tue Apr 16 07:32:25 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.
On Tue, Apr 16, 2013 at 11:27 AM, Paul Benedict <pbenedict at apache.org> wrote:
> Paul, what are your thoughts of creating an SPI that allow implementations
> to hook into F/J? I am thinking that the SE API could be used if an EE
> container had a way of participating in the API to create threads.
> On Tue, Apr 16, 2013 at 2:34 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> On Apr 15, 2013, at 11:07 AM, Richard Warburton <
>> richard.warburton at gmail.com> wrote:
>> >> IIRC, the Java EE concurrency folks had been already talked through
>> >> this, and the current outcome is that FJP will gracefully degrade to
>> >> single-threaded (even caller-context) execution when running from within
>> >> the EE container. That will automatically mean the parallel stream
>> >> operations are effectively sequential.
>> > Will it be possible to utilise any of the constructs specified by JSR
>> AFAIK not at the moment.
>> I think the difficultly here is how to expose control of the F/J pool to
>> the framework/container developer. This is not something we want most
>> developers to fiddle with.
>> > Even if this is a manual process. It seems a little confusing for there
>> > be an active JSR around providing concurrency in an EE context and for
>> > SE concurrency constructs to be unable to use it.
>> > regards,
>> > Richard Warburton
>> > http://insightfullogic.com
>> > @RichardWarburto <http://twitter.com/richardwarburto>
More information about the lambda-dev