Point lambdafications in java.io

[Brian Goetz]

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

Yep.

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