Point lambdafications in java.io

Brian Goetz brian.goetz at oracle.com
Tue Jun 18 12:29:02 PDT 2013

> I think that Stream and Input/Output Stream are different enough that I
> find the word "Stream" in CloseableStream confusing.


> For one thing, Stream is not a base class of InputStream and
> OutputStream, as one might expect given the name.

Yeah, that's unfortunate, but I think we've already crossed that river. 
  But that doesn't mean we shouldn't seek to minimize the damage.  We've 
done a lot of good work to reduce the API down from dozens of interfaces 
down to a handful; I like the idea of having only Stream and 
{Int,Long,Double}Stream, and that's it.  Whenever you have FooStream and 
BarStream you will inevitably be asked for FooBarStream.  Saying no to 
FooStream is a good way to avoid that problem.

> What does moving AutoCloseable up to Stream mean?

It means Stream acquires a close() method.  We get to define what the 
interactions between close() and other stream methods is, and what 
should happen if we use a stream after closing it.

Implementing AutoCloseable means that you can be used with the 
try-with-resources construct.  Here's the path the libraries team took here:

1.  It would be nice to have some static methods for "give me a stream 
of files matching certain characteristics" (e.g., Files.walk(dir)).

2.  The naive implementation doesn't give the user a way to release the 
open directory resource.

3.  Let's have CloseableStream, which implements AutoCloseable, so you 
can use these in a TWR to release the resource.  Then Files.walk can 
return CloseableStream.

My question is whether a separate abstraction is needed and/or 
warranted.  My intuition (now that I look at it more closely) leans 
towards "no".

> It is the InputStream source that is Closeable, not the Stream of results?

The idea is that closing the Stream causes the underlying resources to 
be closed in turn.

More information about the lambda-libs-spec-observers mailing list