Java streams lazy vs fusion vs short-circuiting

I'm trying to form a cocise and conherent understanding of the application of lazy evaluation within the Java streams API.

Here is what I currently understand:

  • elements are only consumed as they are needed, i.e. streams are lazy, and intermediate operations are lazy such that e.g. filter, will only filter when it is required to.
  • intermediate operations may be fused together (if they are stateless).
  • short-circuiting operations do not need to process the entire stream.

What I want to do is bring all these ideas together and ensure I'm not misrepresenting anything. I'm finding it tricky because whenever I read any literature on Java streams, it goes on to say they're lazy or utilise lazy evaluation, and then very much interchangeably starts talking about optimisations such as fusion and short-circuiting.

So would I be right in saying the following?

  • fusion is how lazy evaluation has been implemented in the stream API - i.e. an element is consumed, and operations are fused together wherever possible. I'm thinking that if fusion didn't exist then surely we'd be back to eager evaluation as the alternative would just be to process all elements for each intermediate operation before moving onto the next?

  • short-circuiting is possible without fusion or lazy evaluation but is very much helped in the context of streams by these the implementation of these two principles?

I'd appreciate any further insight and clarity on this.

Answers


As for fusion. Let's imagine here's a map operation:

.map(x -> x.squash())

It's stateless and it just transforms any input according to the specified algorithm (in our case squashes them). Now the filter operation:

.filter(x -> x.getColor() != YELLOW)

It's also stateless and it just removes some elements (in our case yellow ones). Now let's have a terminal operation:

.forEach(System.out::println)

It just displays the input elements to the terminal. The fusion means that all intermediate stateless operations are merged with terminal consumer into single operation:

.map(x -> x.squash())
.filter(x -> x.getColor() != YELLOW)
.forEach(System.out::println)

The whole pipeline is fused into single Consumer which is connected directly to the source. When every single element is processed, the source spliterator just executes the combined consumer, the stream pipeline does not intercept anything and does not perform any additional bookkeeping. That's fusion. Fusion does not depend on short-circuiting. It's possible to implement streams without fusion (execute one operation, take the result, execute the next operation, taking the control after each operation back to the stream engine). It's also possible to have fusion without short-circuiting.


Need Your Help

What is the iBeacon Bluetooth Profile

ios bluetooth bluetooth-lowenergy reverse-engineering ibeacon

I'd like to create my own iBeacon with some bluetooth low energy dev kits. Apple has yet to release a specification for iBeacons, however a few hardware developers have reverse Engineered the iBeacon

Do you know of a bleeding-edge HTML5 leveraging, legacy-ignoring JavaScript framework?

javascript jquery ajax html5 extjs

What's the best framework (sort of jquery, extjs, etc like) to use if I'd like to intensively use all the freshest technologies of the HTML5 stack provided by modern browsers (Firefox 7, Safari 5, ...