Identifying resource-using streams

[Brian Goetz]

> Regarding: “This was a tradeoff to bring IO-wrapping streams into the
> story without polluting the majority of streams with resource management
> considerations (since most streams do not hold resources.)”
>
> You don’t know that, really.
>
> Only in the case where a Stream is created and used within a small
> method and it very obviously doesn’t deal with IO or other resources is
> it safe to not close it.

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.

> It’s unfortunate that the API makes not
> releasing resources the more convenient usage pattern because that’s
> going to guarantee that such use patterns will make their way into
> situations where there are resources to be released.

No, polluting every use of streams with resource management when only a 
tiny fraction will hold resources would have been unfortunate.  Making 
resources release impossible would have been unfortunate.

The alternate argument is that every terminal should close() its source, 
regardless of whether that does anything or not.  The EG considered 
this, and decided that this was a violation of the rule: "the party 
acquiring the resource has responsibility for releasing the resource." 
(This is the same reason reading the last line of a file does not close 
it.)