<p dir="ltr">One of the design principles for this API is that parallel transforms will not be automatic. There is a parallel() method for that. This hasn&#39;t changed, right?</p>
<p dir="ltr">I maintain strict control over which parts of my code are serial and which are parallel. I believe this is the best approach for productivity and maintainability. Just because someone could insert a parallel() somewhere upstream and thereby create a mess doesn&#39;t matter to me. There are lots of ways to break code and this is not one of the ways that I am defending against.</p>

<p dir="ltr">It seems to me that the ground rules are changing, driven by some latent aspects of the implementation. But I&#39;ll have to see if/how these changes affect my sample code before I can respond.</p>
<p dir="ltr">Joe</p>
<div class="gmail_quote">On Mar 22, 2013 2:33 PM, &quot;Brian Goetz&quot; &lt;<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
for-loops that mutate uplevel locals or use nonlocal control flow will not be so transformable.  (Supporting this was one of the goals of BGGA.)<br>
<br>
Transforming an existing for-loop, and then discovering that your stream source is controlled by other code that has decided to go parallel on you without you realizing it, will cause trouble.<br>
<br>
So the constraints on &quot;when can I use statefulness in my lambdas&quot; is pretty much as messy as &quot;when is it safe to mutate fields of objects&quot;. (This problem was big enough it needed a whole book.)<br>
<br>
On 3/22/2013 2:26 PM, Joe Bowbeer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Doug writes<br>
<br>
 &gt;don&#39;t belong in any stream op not called forEach<br>
<br>
I&#39;m with you there.<br>
<br>
Will we be able to advertise that one can easily rewrite any &#39;for&#39; loop<br>
using each()?<br>
<br>
This is one of those useful talking points in the introductory articles:<br>
See, these new features aren&#39;t completely alien. You can take any for<br>
loop and transform it like so... If so, then forEach is an apt,<br>
intuitive name. Otherwise, some distance is needed.<br>
<br>
Joe<br>
<br>
On Mar 22, 2013 11:57 AM, &quot;Doug Lea&quot; &lt;<a href="mailto:dl@cs.oswego.edu" target="_blank">dl@cs.oswego.edu</a><br>
&lt;mailto:<a href="mailto:dl@cs.oswego.edu" target="_blank">dl@cs.oswego.edu</a>&gt;&gt; wrote:<br>
<br>
    On 03/22/13 10:07, Joe Bowbeer wrote:<br>
<br>
        Stateful programming has its issues but that ship has already<br>
        sailed (in Java).<br>
<br>
<br>
    Although it is worth bearing in mind that most stream functionality<br>
    wrt Collections exploits the fact that operations within<br>
    traversals are already known to avoid some of the worst unexpected<br>
    side-effects -- mutating a collection while you are traversing.<br>
    Which normally leads to ConcurrentModificationExceptio<u></u>__n for<br>
    iterators. A variant of this is preserved when applicable<br>
    in Spliterator implementations. People learn quickly to avoid them.<br>
    (That&#39;s the subject of some of the specs Paul Sandoz has been<br>
    adding, which can&#39;t be nailed down very well in general because<br>
    they are quality-of-implementation issues, but he is trying anyway :-)<br>
<br>
    Anyway, as the chief advocate for cool mutative algorithmics<br>
    in this group, I&#39;m still in favor of saying they don&#39;t belong<br>
    in any stream op not called forEach.<br>
<br>
    -Doug<br>
<br>
<br>
</blockquote>
</blockquote></div>