Identifying resource-using streams

[Brian Goetz]

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