Java 8 in a JEE Environment

Paul Sandoz paul.sandoz at oracle.com
Tue Apr 16 07:55:46 PDT 2013


On Apr 16, 2013, at 4:27 PM, 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.
> 

IIUC F/J already contains the fundamentals: ForkJoinPool/ForkJoinThread. So the question is how can EE inform the stream framework of the policies that should be used when one does the following in say a web app:

  list.parallelStream().map(...).filter(...).collect(...)

IMHO providing arguments to parallelStream is not the solution, most developers will not know what to do with them properly and nor should they have to, and it is not portable.

Maybe one solution is an app thread executing in a EE container must be is a ForkJoinWorkerThread? (if not the F/J common pool is used). That allows for different apps in the same container to have different policies.

Maybe another solution is all apps from within the same EE container use the common pool configured via system properties as Brian indicates.

Paul.


> Paul
> 
> 
> 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 236?
> 
> 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.
> 
> Paul.
> 
> > Even if this is a manual process.  It seems a little confusing for there to
> > be an active JSR around providing concurrency in an EE context and for new
> > 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 mailing list