Round 2 feedback

[Patrick Wright]

As long as there are clearly defined entry points to the parallel/threaded
methods in the JDK, they can be identified by an automated process. If you
are using a framework such as JEE where using that sort of feature would be
in violation of framework contracts, then build a wrapper to sniff such
libraries out and reject them at build time. The same goes for others, like
GAE, which may have these restrictions. I don't think that methods in the
JDK should be altered to reduce the perceived risks to one part of the
community - the JEE developers - as long as there is a reasonable
workaround, especially one that can be automated.

Cheers,
Patrick


On Wed, Feb 13, 2013 at 3:29 PM, Michael Nascimento <misterm at gmail.com>wrote:

> On Sun, Feb 10, 2013 at 10:42 AM, Patrick Wright <pdoubleya at gmail.com>
> wrote:
> >> - Here is my greatest concern so far: parallel streams in their current
> >> form will cause Java EE applications to fail miserably. In such
> >> environments, threads cannot be freely created and all types of leaks
> and
> >> exceptions can happen if one calls a method in a non-container managed
> >> thread. Since calling parallelStream is cheap, I guess people will do it
> >> often and it will be hard for Java EE developers to find out if any
> >> third-party Java SE 8 code is safe to call or not - and enterprise
> >> developers unaware of such restrictions, which are unfortunately the
> >> majority, will be puzzled by never seen exceptions or erratic behaviour
> in
> >> production. My suggestion would be to add a parameter to parallelStream
> >> and
> >> parallel which is an abstraction to thread management,  forcing people
> to
> >> think about it. Then one can construct a wrapper over the
> >> container-specific API for now and Java EE 8 can provide the
> standardized
> >> one;
> >
> >
> > It seems this is rather an ideal use for a Checkstyle rule or similar
> > style-enforcer, e.g. to find calls to .parallelXXX and forbid them?
>
> Well, not really since it can be in an "innocent" library somewhere or
> in the future even inside the VM library code itself.
>
> Regards,
> Michael
>