Simplifying sequential() / parallel()

[Joe Bowbeer]

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't
changed, right?

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'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.

It seems to me that the ground rules are changing, driven by some latent
aspects of the implementation. But I'll have to see if/how these changes
affect my sample code before I can respond.

Joe
On Mar 22, 2013 2:33 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> 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.)
>
> 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.
>
> So the constraints on "when can I use statefulness in my lambdas" is
> pretty much as messy as "when is it safe to mutate fields of objects".
> (This problem was big enough it needed a whole book.)
>
> On 3/22/2013 2:26 PM, Joe Bowbeer wrote:
>
>> Doug writes
>>
>>  >don't belong in any stream op not called forEach
>>
>> I'm with you there.
>>
>> Will we be able to advertise that one can easily rewrite any 'for' loop
>> using each()?
>>
>> This is one of those useful talking points in the introductory articles:
>> See, these new features aren't completely alien. You can take any for
>> loop and transform it like so... If so, then forEach is an apt,
>> intuitive name. Otherwise, some distance is needed.
>>
>> Joe
>>
>> On Mar 22, 2013 11:57 AM, "Doug Lea" <dl at cs.oswego.edu
>> <mailto:dl at cs.oswego.edu>> wrote:
>>
>>     On 03/22/13 10:07, Joe Bowbeer wrote:
>>
>>         Stateful programming has its issues but that ship has already
>>         sailed (in Java).
>>
>>
>>     Although it is worth bearing in mind that most stream functionality
>>     wrt Collections exploits the fact that operations within
>>     traversals are already known to avoid some of the worst unexpected
>>     side-effects -- mutating a collection while you are traversing.
>>     Which normally leads to ConcurrentModificationExceptio**__n for
>>     iterators. A variant of this is preserved when applicable
>>     in Spliterator implementations. People learn quickly to avoid them.
>>     (That's the subject of some of the specs Paul Sandoz has been
>>     adding, which can't be nailed down very well in general because
>>     they are quality-of-implementation issues, but he is trying anyway :-)
>>
>>     Anyway, as the chief advocate for cool mutative algorithmics
>>     in this group, I'm still in favor of saying they don't belong
>>     in any stream op not called forEach.
>>
>>     -Doug
>>
>>
>>