Simplifying sequential() / parallel()
joe.bowbeer at gmail.com
Fri Mar 22 16:21:48 PDT 2013
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
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
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.
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.
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lambda-libs-spec-experts