Identifying resource-using streams

[Brian Goetz]

> Regarding: “Which is the overwhelmingly common case.  Most stream
> sources are
> collections or other non-resource-holding sources.  Most streams are
> created and consumed in the same place.  This is how the API was
> designed, how all the examples work, and by all evidence, how it is
> being used.”
>
> You keep saying that, and maybe there’s a lot of ad-hoc Streams use that
> I don’t even think about, but almost all of the cases where I plan to
> use Streams involve reading the contents of directories, reading the
> contents of files or reading the contents of JAR files. All are
> cases where resources are involved and the processing too complicated to
> fit in a single method.

That may be the case.  In which case, though, maybe you should accept 
the fact that you are outside the target profile for this API, and view 
the glass as half full (it can support your use case at all!) rather 
than half empty ("please distort it for the other 99% of users to make 
it easier for me")?  In fact, we even distorted it a little bit for you; 
what you're complaining of is that we didn't distort it enough.

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

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