capturing (or not) mutable local variables

[Jim Mayer]

Ended on my part... but do note that using "Collections.synchronizedList(new
ArrayList())" does NOT make Vincent's example thread safe.  The expectation
that virtually all developers would have is that applying the example to
{1,2,3,4} would be {1,4,9,16}, but with parallel execution {4,9,16,1} would
be a perfectly legal outcome.  Now, if his example had used a Set instead of
a list THEN the adding the synchronization would have generated the expected
result.

-- Jim

On Mon, Nov 22, 2010 at 7:08 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> > final List square = new ArrayList();
> > list.forEach(#{ e ->  square.add(e*e); });
> >
> > How is that really different from your simple broken example? Why
> > would we be ok with that one, but not with yours? Should not we be all
> > equally screaming 'please do not make this non thread safe closure
> > passable to this multithreaded method'?.
>
> One significant difference is that the reference-based version *can* be
> made
> thread-safe by making the referent thread-safe (say, by replacing "new
> ArrayList()" with "Collections.synchronizedList(new ArrayList())").  The
> primitive version cannot realistically be made thread-safe.
>
> (Effectively, you have provided the argument why we should not have a
> list.forEach() all -- it demands that the client use side-effects to
> achieve
> the desired results, which invites trouble.)
>
> In any case, I think it is time to close this discussion.  You've made your
> point, some people agree with you, and some others disagree.  But we do not
> intend to lift this restriction at this time, and I don't think further
> discussion will bring to light any issues that have not already been
> considered.  We can always revisit this issue in a future iteration
> (choosing
> not to lift a restriction now does not foreclose on our ability to do so
> later).
>
>
>
>