Re: Identifying resource-using streams

[Timo Kinnunen]

Hi, 


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. 


Since anyone who has a reference to a stream can call 

Stream.onClose(myVeryImportantResourceReleaser), any stream that escapes the current scope could hold resources. Likewise, any stream received from some other scope could hold resources even if it’s just a lowly IntStream. For example, if you use an instance of a Supplier<Stream<T>> in your code then you should close all of the streams coming from that.


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








-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Brian Goetz
Sent: ‎Friday‎, ‎April‎ ‎18‎, ‎2014 ‎22‎:‎21
To: Erik Costlow, lambda-dev at openjdk.java.net





Currently, the text in the Javadoc is your only hint.  It is never 
*wrong* to use try-with-resources, or to call the close() method 
directly (most implementations do nothing), but most of the time is 
unnecessary.  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.)

The referenced e-mail goes back to a time when we were trying harder to 
represent this in the static type system; we concluded that the 
additional specificity didn't warrant the additional API surface area. 
Instead, we clarified the specification of AutoCloseable.

We *could* choose to use an annotation to try and capture this, but I 
don't think its worth it (if we did, we'd want to write a pluggable 
checker using JSR-308 as well.)  We haven't gone down this route for 
most of the JDK; if we were going to do this at all, we'd want to make a 
much bigger commitment to the use of safety annotations.


On 4/17/2014 6:51 PM, Erik Costlow wrote:
> I was looking through the javadoc of different items and noticed an
> area where some machine-parseable documentation (like an annotation)
> may help developers produce better applications.
>
>
>
> NIO's Files.lines returns a Stream<String> that uses a filesystem
> resource. This is correctly listed in the javadoc which says, "If
> timely disposal of file system resources is required, the
> try-with-resources construct should be used" and the Stream api
> itself says "Generally, only streams whose source is an IO channel
> (such as those returned by Files.lines(Path, Charset)) will require
> closing."
>
>
>
> Given that all streams are AutoCloseable but only some merit user
> attention, has consideration been given towards indicating (to
> automated tools) which streams the users should close?
>
>
>
>
>
>
>
> Or was this question covered already in
> http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010394.html
> ?
>