Point lambdafications in java.io

Joe Bowbeer joe.bowbeer at gmail.com
Wed Jun 19 12:47:30 PDT 2013

My position is: We should do it right if we do it.

Where "right" is well above the low-bar set by finalizer.

I'm interested in seeing a more detailed proposal.

I also think there is some room to explore other options for the File case.

URL is another place where this use case may surface, and is also a place
where "Stream" has another meaning, for example: URL.openStream() and


On Wed, Jun 19, 2013 at 7:12 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Right, and that's just one problem.  The current implementation of
> CloseableStream is pretty much broken; not only do the methods do not
> return CloseableStream, but close()ing the CS does not have any effect on
> the stream.  So, I think the current CS is just too weak and at the same
> time consumes too much API surface area.  And creating a separate
> bulletproof CS abstraction is more than we can do now.  (And I never really
> liked having any FooableStream interfaces, because they invariably
> proliferate, and you end up in situations where you can you get a
> FooableStream or a BarableStream but you really want a
> FooableBarableStream.  Better not to go there at all.)
> But, we can bring AutoCloseable into Stream itself with relatively litle
> pain if we don't demand absolute perfection.  It is fairly easy to
> implement AC in Stream and have close() actually be reflected in the
> behavior of other stream methods with little intrusion and no additional
> runtime performance overhead (we can piggyback on an existing stream reuse
> check.)
> Your example about concat() is a good one, but I think it points the other
> way.  My first attempt at incorporating AutoCloseable into Stream missed
> that case.  But if all streams are Closeable, it is possible to hit that
> case in the second round.  With a separate CloseableStream abstraction, it
> will be impractical to ever hit that case.
> So I think we have two choices.
>  - No close support whatsoever.  Kill existing CloseableStream.  That
> means no use of TWR on IO-backed streams, and no way to release the
> resources except maybe after successful exhaustion of the input.
>  - Some reasonable best-effort attempt at "all streams are Closeable",
> like the one I've outlined.
> It sounds like your position is "if we can't do it perfectly, don't try?"
> On 6/19/2013 6:50 AM, Joe Bowbeer wrote:
>> Update:
>> Some of my comments were based on the assumption that all streams would
>> be Closeable, the way all IO streams are closeable.
>> The problem with adding closeable stream separately is that none of the
>> closeable streams' stream methods return closeable streams. That, and
>> also that there are no closeable primitive streams.
>> On Jun 19, 2013 3:36 AM, "Joe Bowbeer" <joe.bowbeer at gmail.com
>> <mailto:joe.bowbeer at gmail.com>**> wrote:
>>     I'm not in favor. As an implementer of custom IO streams, I'm aware
>>     of the burden that proper close() implementation adds, as well as
>>     the lack of any uses in many contexts. You can't(*) add close and
>>     expect best effort to be acceptable. There are unit tests, and close
>>     is expected to propagate (right?), e.g., in concat'd and zipped and
>>     merged and filtered streams.
>>     As Remi points out, this would also require diluting the static
>>     analysis checks and editor warnings that are in place to ensure
>>     proper use of Closeables. From the programmer's point of view, every
>>     Stream would have to be treated as if it were an IO stream.
>>     Joe
>>     On Jun 18, 2013 6:48 PM, "Brian Goetz" <brian.goetz at oracle.com
>>     <mailto:brian.goetz at oracle.com**>> wrote:
>>         I did a quick look at the code, this would be very easy to
>>         implement by piggybacking on top of the existing checking for
>>         stream re-use.  Just as
>>            Stream s = ...
>>            s.forEach(...)
>>            s.forEach(...) // throws ISE
>>         fails because the stream is being "reused", we can have future
>>         stream operations fail with ISE if they are initiated after the
>>         stream is closed.  For the example behavior you suggest,
>>         probably anything could happen.  But we can make a good-faith
>>         effort to prevent future stream operations from proceeding
>>         (which, Mike noted, is more than a lot of the existing
>>         Autocloseable IO classes do.)
>>         On 6/18/2013 12:30 PM, Sam Pullara wrote:
>>             I am very much in favor of a way to signal to the stream to
>>             relinquish resources so that you don't have to exhaust it to
>>             ensure that it is cleaned up. That said, without things like
>>             takeWhile() I'm not sure that there are many cases where you
>>             can close the stream unless you are in an exception state.
>>             What would be the semantics of something like this:
>>             Stream stream = list.stream();
>>             stream.forEach(o -> stream.close());
>>             Sam
>>             On Jun 18, 2013, at 9:05 AM, Brian Goetz
>>             <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com**>>
>> wrote:
>>                 The libraries team added the following methods to
>>                 java.io <http://java.io> and java.nio, with discussion
>>                 on corelibs-dev:
>>                 In java.io.BufferedReader:
>>                    Stream<String> lines()
>>                 In java.nio.Files, static methods for:
>>                    CloseableStream<Path> list(Path dir) throws
>> IOException;
>>                    CloseableStream<Path> walk(Path start, int maxDepth,
>>                 FileVisitOption... options) throws IOException
>>                    CloseableStream<Path> walk(Path start,
>>                 FileVisitOption... options) throws IOException
>>                    CloseableStream<Path> find(Path start,
>>                                             int maxDepth,
>>                                             BiPredicate<Path,
>>                 BasicFileAttributes> matcher,
>>                                             FileVisitOption... options)
>>                          throws IOException
>>                    CloseableStream<String> lines(Path path, Charset cs)
>>                 throws IOException
>>                 CloseableStream simply extends Stream and AutoCloseable,
>>                 making it suitable for use with try-with-resources:
>>                 public interface CloseableStream<T> extends Stream<T>,
>>                 AutoCloseable {
>>                      void close();
>>                 }
>>                 Should we consider moving AutoCloseable up to Stream and
>>                 friends, and get rid of CloseableStream?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130619/c1452cf1/attachment.html 

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