Identifying resource-using streams

[Paul Sandoz]

On Apr 21, 2014, at 5:23 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
>> All of the above brings up another unfortunate feature of the API:
>> a Stream is very close to being an immutable stateless builder for
>> stream-like processing but it is neither immutable nor stateless.
> 
> You are referring, I presume, to the desire to have "detached streams", where streams could be reusable pipelines of pure behavior, with no source attached, and essentially be delayed functions which could be applied on a source.
> 
> You may be surprised to find that this is basically where we started, and would have liked to have supported this use case.  However, it turned out incorporating this goal substantially complicated the design and API, and so after quite a bit of exploration, we did the prudent thing and scaled back our target.  However, that shouldn't stop you: if you want what you call "stateless streams", just do this:
> 
> Function<IntStream, int> delayedApply =
>  is -> is.filter(...).map(...).reduce(...)
> 
> and you've got what you asked for.
> 

... and we made good use of that in the Stream unit tests so that the same pipeline can be executed over many different sources.

Also of note is that stream construction has the notion of late binding, generally it is preferably to bind to the source when the terminal operation commences, but for some sources this is not possible e.g. BufferedReader::lines.

We could of easily chosen to perform a close after the terminal operation completes but chose not to. The only place the framework explicitly closes a stream is for those returned by the flatMap function.


> In any case, I think you're just venting that this isn't the API *you* would have designed or the perfect API for your situation.  Which is fine; go build that!  (Contrary to popular belief, we would be thrilled to see people go off and build *even better* APIs than the ones we've included in the JDK.)
> 

Yes, part of the problem i think is people come to the table with different notions of what a "stream" is and it can take time for the dust to settle and understand each other.

The JDK j.u.s.Stream focuses on a particular model, but it is obviously not the only model or stream-like abstraction. There are others such as distributed streams (map/reduce in the large), or a "reactive" async/event-based streams (such as RxJava).

Paul.